作为一名程序员，你是 能够对驱动程序做出自己的选择，并在所需的编程时间和结果的灵活性之间选择可接受的权衡。虽然说驱动程序是“灵活的”可能看起来很奇怪，但我们喜欢这个词，因为它强调设备驱动程序的作用是提供 机制，而不是政策。

As a programmer, you are able to make your own choices about your driver, and choose an acceptable trade-off between the programming time required and the flexibility of the result. Though it may appear strange to say that a driver is "flexible," we like this word because it emphasizes that the role of a device driver is providing mechanism, not policy.

机制和策略之间的区别是 Unix 设计背后的最佳思想之一。大多数编程问题确实可以分为两部分：“要提供什么功能”（机制）和“如何使用这些功能”（策略）。如果这两个问题由程序的不同部分，甚至完全由不同的程序来解决，则软件包更容易开发并适应特定需求。

The distinction between mechanism and policy is one of the best ideas behind the Unix design. Most programming problems can indeed be split into two parts: "what capabilities are to be provided" (the mechanism) and "how those capabilities can be used" (the policy). If the two issues are addressed by different parts of the program, or even by different programs altogether, the software package is much easier to develop and to adapt to particular needs.

例如，图形显示的 Unix 管理分为 X 服务器和窗口和会话管理器，X 服务器了解硬件并为用户程序提供统一的接口，而窗口和会话管理器则在不了解硬件的情况下实现特定策略。人们可以在不同的硬件上使用相同的窗口管理器，不同的用户可以在同一工作站上运行不同的配置。即使完全不同的桌面环境，例如 KDE 和 GNOME，也可以在同一系统上共存。另一个例子是 TCP/IP 网络的分层结构：操作系统提供套接字抽象，它没有实现有关要传输的数据的策略，而不同的服务器负责服务（及其相关策略）。而且， ftpd提供文件传输机制，用户可以使用任何他们喜欢的客户端；命令行和图形客户端都存在，任何人都可以编写新的用户界面来传输文件。

For example, Unix management of the graphic display is split between the X server, which knows the hardware and offers a unified interface to user programs, and the window and session managers, which implement a particular policy without knowing anything about the hardware. People can use the same window manager on different hardware, and different users can run different configurations on the same workstation. Even completely different desktop environments, such as KDE and GNOME, can coexist on the same system. Another example is the layered structure of TCP/IP networking: the operating system offers the socket abstraction, which implements no policy regarding the data to be transferred, while different servers are in charge of the services (and their associated policies). Moreover, a server like ftpd provides the file transfer mechanism, while users can use whatever client they prefer; both command-line and graphic clients exist, and anyone can write a new user interface to transfer files.

就驱动因素而言，同样适用机制和政策的分离。软盘驱动程序不受策略限制，其作用只是将软盘显示为连续的数据块阵列。系统的更高级别提供策略，例如谁可以访问软盘驱动器、是否直接访问驱动器或通过文件系统访问驱动器以及用户是否可以在驱动器上安装文件系统。由于不同的环境通常需要以不同的方式使用硬件，因此尽可能不受策略限制非常重要。

Where drivers are concerned, the same separation of mechanism and policy applies. The floppy driver is policy free—its role is only to show the diskette as a continuous array of data blocks. Higher levels of the system provide policies, such as who may access the floppy drive, whether the drive is accessed directly or via a filesystem, and whether users may mount filesystems on the drive. Since different environments usually need to use hardware in different ways, it's important to be as policy free as possible.

程序员在编写驱动程序时应特别注意这个基本概念：编写内核代码来访问硬件，但不要将特定策略强加给用户，因为不同的用户有不同的需求。驱动程序应该处理使硬件可用的问题，将有关如何使用硬件的所有问题留给 应用程序。如果驱动程序提供对硬件功能的访问而不增加限制，那么它就是灵活的。然而，有时必须做出一些政策决定。例如，数字 I/O 驱动程序可能仅提供对硬件的字节宽度访问，以避免处理各个位所需的额外代码。

When writing drivers, a programmer should pay particular attention to this fundamental concept: write kernel code to access the hardware, but don't force particular policies on the user, since different users have different needs. The driver should deal with making the hardware available, leaving all the issues about how to use the hardware to the applications. A driver, then, is flexible if it offers access to the hardware capabilities without adding constraints. Sometimes, however, some policy decisions must be made. For example, a digital I/O driver may only offer byte-wide access to the hardware in order to avoid the extra code needed to handle individual bits.

您还可以从不同的角度看待驱动程序：它是位于应用程序和实际设备之间的软件层。驱动程序的这种特权角色允许驱动程序程序员准确选择设备的显示方式：不同的驱动程序可以即使对于同一设备也提供不同的功能。实际的驱动程序设计应该在许多不同的考虑因素之间进行平衡。例如，单个设备可以由不同的程序同时使用，并且驱动程序程序员可以完全自由地确定如何处理并发性。您可以独立于其硬件功能在设备上实现内存映射，或者可以提供用户库来帮助应用程序员在可用原语之上实施新策略，等等。一个主要的考虑因素是向用户提供尽可能多的选项的愿望与编写驱动程序的时间之间的权衡，以及需要保持简单以免出现错误。

You can also look at your driver from a different perspective: it is a software layer that lies between the applications and the actual device. This privileged role of the driver allows the driver programmer to choose exactly how the device should appear: different drivers can offer different capabilities, even for the same device. The actual driver design should be a balance between many different considerations. For instance, a single device may be used concurrently by different programs, and the driver programmer has complete freedom to determine how to handle concurrency. You could implement memory mapping on the device independently of its hardware capabilities, or you could provide a user library to help application programmers implement new policies on top of the available primitives, and so forth. One major consideration is the trade-off between the desire to present the user with as many options as possible and the time you have to write the driver, as well as the need to keep things simple so that errors don't creep in.

不受政策影响的驱动因素有一些典型特征。其中包括对同步和异步操作的支持、多次打开的能力、充分利用硬件功能的能力以及缺乏软件层来“简化事物”或提供与策略相关的操作。此类驱动程序不仅对最终用户来说工作得更好，而且也更容易编写和维护。无策略实际上是软件设计者的共同目标。

Policy-free drivers have a number of typical characteristics. These include support for both synchronous and asynchronous operation, the ability to be opened multiple times, the ability to exploit the full capabilities of the hardware, and the lack of software layers to "simplify things" or provide policy-related operations. Drivers of this sort not only work better for their end users, but also turn out to be easier to write and maintain as well. Being policy-free is actually a common target for software designers.

事实上，许多设备驱动程序是与 用户程序可帮助配置和访问目标设备。这些程序的范围从简单的实用程序到完整的图形应用程序。示例包括tunelp 程序，它调整并行端口打印机驱动程序的运行方式，以及图形卡ctl 实用程序是 PCMCIA 驱动程序包的一部分。通常还提供客户端库，它提供不需要作为驱动程序本身的一部分实现的功能。

Many device drivers, indeed, are released together with user programs to help with configuration and access to the target device. Those programs can range from simple utilities to complete graphical applications. Examples include the tunelp program, which adjusts how the parallel port printer driver operates, and the graphical cardctl utility that is part of the PCMCIA driver package. Often a client library is provided as well, which provides capabilities that do not need to be implemented as part of the driver itself.

本书的范围是内核，因此我们尽量不涉及政策问题或应用程序或支持库。有时我们会讨论不同的策略以及如何支持它们，但我们不会详细介绍使用设备的程序或它们执行的策略。但是，您应该了解，用户程序是软件包的组成部分，甚至无策略软件包也是随 将默认行为应用于底层机制的配置文件。

The scope of this book is the kernel, so we try not to deal with policy issues or with application programs or support libraries. Sometimes we talk about different policies and how to support them, but we won't go into much detail about programs using the device or the policies they enforce. You should understand, however, that user programs are an integral part of a software package and that even policy-free packages are distributed with configuration files that apply a default behavior to the underlying mechanisms.

在 Unix 系统中， 多个并发进程 负责不同的任务。每个进程都需要系统资源，无论是计算能力、内存、网络连接还是其他资源。内核是负责处理所有此类请求的一大块可执行代码。虽然不同内核任务之间的区别并不总是清晰可见，但内核的角色可以分为（如图1-1所示）为以下部分：

In a Unix system, several concurrent processes attend to different tasks. Each process asks for system resources, be it computing power, memory, network connectivity, or some other resource. The kernel is the big chunk of executable code in charge of handling all such requests. Although the distinction between the different kernel tasks isn't always clearly marked, the kernel's role can be split (as shown in Figure 1-1) into the following parts:

图 1-1。内核的分割视图

Figure 1-1. A split view of the kernel

Linux 查看设备的方式 区分三种基本设备类型。每个模块通常实现这些类型之一，因此可分为字符模块、块模块或网络模块。这种将模块划分为不同类型或类别的做法并不是严格的。程序员可以选择构建在单个代码块中实现不同驱动程序的巨大模块。然而，优秀的程序员通常会为他们实现的每个新功能创建不同的模块，因为分解是可伸缩性和可扩展性的关键要素。

The Linux way of looking at devices distinguishes between three fundamental device types. Each module usually implements one of these types, and thus is classifiable as a char module, a block module, or a network module. This division of modules into different types, or classes, is not a rigid one; the programmer can choose to build huge modules implementing different drivers in a single chunk of code. Good programmers, nonetheless, usually create a different module for each new functionality they implement, because decomposition is a key element of scalability and extendability.

这三个类是：

The three classes are:

网络接口不是面向流的设备，因此无法像/dev/tty1那样轻松映射到文件系统中的节点。Unix方式提供 对接口的访问仍然是通过为其分配唯一的名称（例如eth0），但该名称在文件系统中没有相应的条目。内核和网络设备驱动程序之间的通信与字符和块驱动程序之间的通信完全不同。内核调用与数据包传输相关的函数，而不是read和 write 。

Not being a stream-oriented device, a network interface isn't easily mapped to a node in the filesystem, as /dev/tty1 is. The Unix way to provide access to interfaces is still by assigning a unique name to them (such as eth0), but that name doesn't have a corresponding entry in the filesystem. Communication between the kernel and a network device driver is completely different from that used with char and block drivers. Instead of read and write, the kernel calls functions related to packet transmission.

还有其他与上述设备类型正交的驱动程序模块分类方法。一般来说，某些类型的驱动程序与给定类型设备的附加内核支持功能层一起工作。例如，人们可以谈论 通用串行总线（USB）模块、串行模块、SCSI 模块等。每个 USB 设备都由与 USB 子系统配合使用的 USB 模块驱动，但设备本身在系统中显示为字符设备（例如 USB 串行端口）、块设备（USB 存储卡读卡器）或网络设备（USB 以太网接口）。

There are other ways of classifying driver modules that are orthogonal to the above device types. In general, some types of drivers work with additional layers of kernel support functions for a given type of device. For example, one can talk of universal serial bus (USB) modules, serial modules, SCSI modules, and so on. Every USB device is driven by a USB module that works with the USB subsystem, but the device itself shows up in the system as a char device (a USB serial port, say), a block device (a USB memory card reader), or a network device (a USB Ethernet interface).

最近，其他类别的设备驱动程序已添加到内核中，包括 FireWire 驱动程序和 I2O 驱动程序。与处理 USB 和 SCSI 驱动程序的方式相同，内核开发人员收集了类范围的功能并将其导出给驱动程序实现者，以避免重复工作和错误，从而简化和加强了编写此类驱动程序的过程。

Other classes of device drivers have been added to the kernel in recent times, including FireWire drivers and I2O drivers. In the same way that they handled USB and SCSI drivers, kernel developers collected class-wide features and exported them to driver implementers to avoid duplicating work and bugs, thus simplifying and strengthening the process of writing such drivers.

除了设备驱动程序之外，其他功能（包括硬件和软件）也在内核中进行了模块化。 一个常见的例子是文件系统。文件系统类型决定了如何在块设备上组织信息以表示目录和文件树。这样的实体不是设备驱动程序，因为没有与信息的放置方式相关联的显式设备；相反，文件系统类型是软件驱动程序，因为它将低级数据结构映射到高级数据结构。文件系统决定文件名的长度以及每个文件的哪些信息存储在目录条目中。这文件系统模块必须通过将文件名和路径（以及其他信息，例如访问模式）映射到存储在数据块中的数据结构来实现访问目录和文件的最低级别的系统调用。这样的接口完全独立于磁盘（或其他介质）的实际数据传输，这是由块设备驱动程序完成的。

In addition to device drivers, other functionalities, both hardware and software, are modularized in the kernel. One common example is filesystems. A filesystem type determines how information is organized on a block device in order to represent a tree of directories and files. Such an entity is not a device driver, in that there's no explicit device associated with the way the information is laid down; the filesystem type is instead a software driver, because it maps the low-level data structures to high-level data structures. It is the filesystem that determines how long a filename can be and what information about each file is stored in a directory entry. The filesystem module must implement the lowest level of the system calls that access directories and files, by mapping filenames and paths (as well as other information, such as access modes) to data structures stored in data blocks. Such an interface is completely independent of the actual data transfer to and from the disk (or other medium), which is accomplished by a block device driver.

如果您想到 Unix 系统对底层文件系统的依赖程度，您就会意识到这样的软件概念对于系统操作至关重要。解码文件系统信息的能力处于内核层次结构的最低级别，并且至关重要；即使你为你的新 CD-ROM 编写了一个块驱动程序，如果你不能运行ls或cp ，它也是无用的在其托管的数据上。Linux 支持文件系统模块的概念，其软件接口声明可以在文件系统 inode、目录、文件和超级块上执行的不同操作。对于程序员来说，实际上需要编写文件系统模块是很不寻常的，因为官方内核已经包含了最重要的文件系统类型的代码。

If you think of how strongly a Unix system depends on the underlying filesystem, you'll realize that such a software concept is vital to system operation. The ability to decode filesystem information stays at the lowest level of the kernel hierarchy and is of utmost importance; even if you write a block driver for your new CD-ROM, it is useless if you are not able to run ls or cp on the data it hosts. Linux supports the concept of a filesystem module, whose software interface declares the different operations that can be performed on a filesystem inode, directory, file, and superblock. It's quite unusual for a programmer to actually need to write a filesystem module, because the official kernel already includes code for the most important filesystem types.

安全是一个日益 现代重要的关注点。我们将讨论整本书中出现的与安全相关的问题。然而，有一些现在值得一提的一般概念。

Security is an increasingly important concern in modern times. We will discuss security-related issues as they come up throughout the book. There are a few general concepts, however, that are worth mentioning now.

系统中的任何安全检查都是由内核代码强制执行的。如果内核存在安全漏洞，那么整个系统也存在漏洞。在官方内核发行版中，只有授权用户才能加载模块；系统调用init_module检查调用进程是否是 授权将模块加载到内核中。因此，当运行官方内核时，只有超级用户^{[ 1 ]}或成功获得特权的入侵者才能利用特权代码的力量。

Any security check in the system is enforced by kernel code. If the kernel has security holes, then the system as a whole has holes. In the official kernel distribution, only an authorized user can load modules; the system call init_module checks if the invoking process is authorized to load a module into the kernel. Thus, when running an official kernel, only the superuser,^[1] or an intruder who has succeeded in becoming privileged, can exploit the power of privileged code.

如果可能，驱动程序编写者应避免在代码中编码安全策略。安全性是一个策略问题，通常最好在系统管理员的控制下在内核中的更高级别进行处理。然而，总有例外。作为设备驱动程序编写者，您应该意识到某些类型的设备访问可能会对整个系统产生不利影响的情况，并且应该提供足够的控制。例如，影响全局资源（例如设置中断线）、可能损坏硬件（例如加载固件）或可能影响其他用户（例如在磁带驱动器上设置默认块大小）的设备操作，通常仅适用于具有足够特权的用户，

When possible, driver writers should avoid encoding security policy in their code. Security is a policy issue that is often best handled at higher levels within the kernel, under the control of the system administrator. There are always exceptions, however. As a device driver writer, you should be aware of situations in which some types of device access could adversely affect the system as a whole and should provide adequate controls. For example, device operations that affect global resources (such as setting an interrupt line), which could damage the hardware (loading firmware, for example), or that could affect other users (such as setting a default block size on a tape drive), are usually only available to sufficiently privileged users, and this check must be made in the driver itself.

当然，驱动程序编写者还必须小心，以避免引入安全错误。C 编程语言很容易犯几种类型的错误。当前许多安全问题都是由缓冲区溢出等造成的 错误，其中程序员忘记检查有多少数据写入了缓冲区，并且数据最终写入到缓冲区末尾之外，从而覆盖了不相关的数据。此类错误可能会危及整个系统，因此必须避免。幸运的是，在设备驱动程序上下文中，避免这些错误通常相对容易，在该上下文中，用户的接口定义得很窄并且受到高度控制。

Driver writers must also be careful, of course, to avoid introducing security bugs. The C programming language makes it easy to make several types of errors. Many current security problems are created, for example, by buffer overrun errors, in which the programmer forgets to check how much data is written to a buffer, and data ends up written beyond the end of the buffer, thus overwriting unrelated data. Such errors can compromise the entire system and must be avoided. Fortunately, avoiding these errors is usually relatively easy in the device driver context, in which the interface to the user is narrowly defined and highly controlled.

其他一些一般性的安全理念也值得牢记。任何从用户进程收到的输入都应该高度怀疑；除非你能验证它，否则永远不要相信它。小心未初始化的内存；从内核获得的任何内存在可供用户进程或设备使用之前都应该清零或以其他方式初始化。否则，信息泄露（数据披露，密码等）可能会导致。如果您的设备解释发送给它的数据，请确保用户无法发送任何可能危害系统的内容。最后，思考一下设备操作可能带来的影响；如果存在可能影响系统的特定操作（例如，在适配器板上重新加载固件或格式化磁盘），那么这些操作几乎肯定应仅限于特权用户。

Some other general security ideas are worth keeping in mind. Any input received from user processes should be treated with great suspicion; never trust it unless you can verify it. Be careful with uninitialized memory; any memory obtained from the kernel should be zeroed or otherwise initialized before being made available to a user process or device. Otherwise, information leakage (disclosure of data, passwords, etc.) could result. If your device interprets data sent to it, be sure the user cannot send anything that could compromise the system. Finally, think about the possible effect of device operations; if there are specific operations (e.g., reloading the firmware on an adapter board or formatting a disk) that could affect the system, those operations should almost certainly be restricted to privileged users.

另外，当从第三方接收软件时，尤其是涉及内核时，也要小心：因为每个人都可以访问源代码，所以每个人都可以破坏和重新编译东西。尽管您通常可以信任发行版中的预编译内核，但您应该避免运行由不受信任的朋友编译的内核 - 如果您不以 root 身份运行预编译的二进制文件，那么您最好不要运行预编译的内核。例如，恶意修改的内核可能允许任何人加载模块，从而通过init_module打开意外的后门。

Be careful, also, when receiving software from third parties, especially when the kernel is concerned: because everybody has access to the source code, everybody can break and recompile things. Although you can usually trust precompiled kernels found in your distribution, you should avoid running kernels compiled by an untrusted friend—if you wouldn't run a precompiled binary as root, then you'd better not run a precompiled kernel. For example, a maliciously modified kernel could allow anyone to load a module, thus opening an unexpected back door via init_module.

请注意，Linux 内核可以编译为不支持任何模块，从而消除任何与模块相关的安全漏洞。当然，在这种情况下，所有需要的驱动程序都必须直接构建到内核本身中。对于 2.2 及更高版本的内核，还可以通过功能机制在系统引导后禁用内核模块的加载。

Note that the Linux kernel can be compiled to have no module support whatsoever, thus closing any module-related security holes. In this case, of course, all needed drivers must be built directly into the kernel itself. It is also possible, with 2.2 and later kernels, to disable the loading of kernel modules after system boot via the capability mechanism.

在深入研究之前 编程时，我们应该评论 Linux 中使用的版本编号方案以及本书涵盖了哪些版本。

Before digging into programming, we should comment on the version numbering scheme used in Linux and which versions are covered by this book.

首先，请注意，每个 Linux 系统中使用的软件包有自己的版本号，并且它们之间通常存在相互依赖性：您需要一个软件包的特定版本来运行另一个软件包的特定版本。Linux发行版的创建者通常会处理匹配软件包的混乱问题，而从预打包发行版安装的用户则不需要处理版本号。另一方面，那些更换和升级系统软件的人在这方面就只能靠自己了。幸运的是，几乎所有现代发行版都支持通过检查包间依赖关系来升级单个包；在满足依赖关系之前，发行版的包管理器通常不允许升级。

First of all, note that every software package used in a Linux system has its own release number, and there are often interdependencies across them: you need a particular version of one package to run a particular version of another package. The creators of Linux distributions usually handle the messy problem of matching packages, and the user who installs from a prepackaged distribution doesn't need to deal with version numbers. Those who replace and upgrade system software, on the other hand, are on their own in this regard. Fortunately, almost all modern distributions support the upgrade of single packages by checking interpackage dependencies; the distribution's package manager generally does not allow an upgrade until the dependencies are satisfied.

要运行我们在讨论中介绍的示例，除了 2.6 内核所需的工具之外，您不需要任何特定版本的工具；任何最新的 Linux 发行版都可以用来运行我们的示例。我们不会详细说明具体要求，因为 如果您遇到任何问题，内核源代码中的文档/更改文件是此类信息的最佳来源。

To run the examples we introduce during the discussion, you won't need particular versions of any tool beyond what the 2.6 kernel requires; any recent Linux distribution can be used to run our examples. We won't detail specific requirements, because the file Documentation/Changes in your kernel sources is the best source of such information if you experience any problems.

就内核而言，偶数内核版本（即 2.6.x ）是用于一般分发的稳定版本。相反，奇怪的版本（例如 2.7.x ）是开发快照，并且非常短暂；其中最新的代表了当前的开发状态，但几天左右就会过时。

As far as the kernel is concerned, the even-numbered kernel versions (i.e., 2.6.x) are the stable ones that are intended for general distribution. The odd versions (such as 2.7.x), on the contrary, are development snapshots and are quite ephemeral; the latest of them represents the current status of development, but becomes obsolete in a few days or so.

本书涵盖了 2.6 版内核。我们的重点是向设备驱动程序编写者展示 2.6.10（我们编写时的当前版本）中可用的所有功能。本书的这个版本不涵盖内核的早期版本。对于那些感兴趣的人，第二版详细介绍了 2.0 到 2.4 版本。该版本仍可在线获取： http: //lwn.net/Kernel/LDD2/。

This book covers Version 2.6 of the kernel. Our focus has been to show all the features available to device driver writers in 2.6.10, the current version at the time we are writing. This edition of the book does not cover prior versions of the kernel. For those of you who are interested, the second edition covered Versions 2.0 through 2.4 in detail. That edition is still available online at http://lwn.net/Kernel/LDD2/.

内核程序员应该意识到开发过程在 2.6 中发生了变化。2.6 系列现在正在接受以前被认为对于“稳定”内核而言太大的更改。除其他外，这意味着内部内核编程接口可以改变，从而可能使本书的部分内容过时；因此，已知文本随附的示例代码可在 2.6.10 中使用，但某些模块无法在早期版本下编译。我们鼓励想要跟上内核编程变化的程序员加入邮件列表并使用参考书目中列出的网站。还有一个网页位于http://lwn.net/Articles/2.6-kernel-api/，其中包含自本书出版以来发生的 API 更改的信息。

Kernel programmers should be aware that the development process changed with 2.6. The 2.6 series is now accepting changes that previously would have been considered too large for a "stable" kernel. Among other things, that means that internal kernel programming interfaces can change, thus potentially obsoleting parts of this book; for this reason, the sample code accompanying the text is known to work with 2.6.10, but some modules don't compile under earlier versions. Programmers wanting to keep up with kernel programming changes are encouraged to join the mailing lists and to make use of the web sites listed in the bibliography. There is also a web page maintained at http://lwn.net/Articles/2.6-kernel-api/, which contains information about API changes that have happened since this book was published.

本文并未具体讨论奇数内核版本。普通用户永远没有理由运行开发内核。然而，尝试新功能的开发人员希望运行最新的开发版本。他们通常会不断升级到最新版本，以修复错误并实现新的功能。但请注意，我们无法保证实验内核^{[ 2 ]}，并且如果您因非当前奇数内核中的错误而遇到问题，则没有人可以帮助您。那些运行奇数版本内核的人通常有足够的技能来深入研究代码，而不需要教科书，这也是我们在这里不讨论开发内核的另一个原因。

This text doesn't talk specifically about odd-numbered kernel versions. General users never have a reason to run development kernels. Developers experimenting with new features, however, want to be running the latest development release. They usually keep upgrading to the most recent version to pick up bug fixes and new implementations of features. Note, however, that there's no guarantee on experimental kernels,^[2] and nobody helps you if you have problems due to a bug in a noncurrent odd-numbered kernel. Those who run odd-numbered versions of the kernel are usually skilled enough to dig in the code without the need for a textbook, which is another reason why we don't talk about development kernels here.

Linux 的另一个特点是它是一个独立于平台的操作系统，而不仅仅是“克隆 PC 的 Unix 克隆”：它目前支持大约 20 种体系结构。本书尽可能与平台无关，所有代码示例至少在x86和x86-64平台上进行了测试。由于代码已在 32 位和 64 位处理器上进行了测试，因此它应该可以在所有其他平台上编译和运行。正如您所期望的，依赖于特定硬件的代码示例并不适用于所有支持的平台， 但这总是在源代码中声明的。

Another feature of Linux is that it is a platform-independent operating system, not just "a Unix clone for PC clones" anymore: it currently supports some 20 architectures. This book is platform independent as far as possible, and all the code samples have been tested on at least the x86 and x86-64 platforms. Because the code has been tested on both 32-bit and 64-bit processors, it should compile and run on all other platforms. As you might expect, the code samples that rely on particular hardware don't work on all the supported platforms, but this is always stated in the source code.

Linux 已获得以下版本 2 的许可 GNU 通用公共许可证 (GPL)，自由软件基金会为 GNU 项目设计的文档。GPL 允许任何人重新分发甚至销售 GPL 涵盖的产品，只要接收者能够访问源代码并能够行使相同的权利。此外，从 GPL 涵盖的产品派生的任何软件产品（如果要重新分发）都必须根据 GPL 发布。

Linux is licensed under Version 2 of the GNU General Public License (GPL), a document devised for the GNU project by the Free Software Foundation. The GPL allows anybody to redistribute, and even sell, a product covered by the GPL, as long as the recipient has access to the source and is able to exercise the same rights. Additionally, any software product derived from a product covered by the GPL must, if it is redistributed at all, be released under the GPL.

这种许可证的主要目标是通过允许每个人随意修改程序来促进知识的增长；与此同时，向公众销售软件的人仍然可以完成他们的工作。尽管目标很简单，但关于 GPL 及其使用的讨论却永无休止。如果您想阅读许可证，您可以在系统中的多个位置找到它，包括 COPYING文件中内核源代码树的顶层目录。

The main goal of such a license is to allow the growth of knowledge by permitting everybody to modify programs at will; at the same time, people selling software to the public can still do their job. Despite this simple objective, there's a never-ending discussion about the GPL and its use. If you want to read the license, you can find it in several places in your system, including the top directory of your kernel source tree in the COPYING file.

供应商经常询问他们是否可以仅以二进制形式分发内核模块。这个问题的答案被故意含糊其辞。到目前为止，二进制模块的分发（只要它们遵守已发布的内核接口）是可以容忍的。但内核的版权由许多开发人员持有，并且并非所有人都同意内核模块不是派生产品。如果您或您的雇主希望在非自由许可证下分发内核模块，您确实需要与您的法律顾问讨论这种情况。另请注意，即使在稳定的内核系列中间，内核开发人员也毫不犹豫地反对在内核版本之间破坏二进制模块。如果可能的话

Vendors often ask whether they can distribute kernel modules in binary form only. The answer to that question has been deliberately left ambiguous. Distribution of binary modules—as long as they adhere to the published kernel interface—has been tolerated so far. But the copyrights on the kernel are held by many developers, and not all of them agree that kernel modules are not derived products. If you or your employer wish to distribute kernel modules under a nonfree license, you really need to discuss the situation with your legal counsel. Please note also that the kernel developers have no qualms against breaking binary modules between kernel releases, even in the middle of a stable kernel series. If it is at all possible, both you and your users are better off if you release your module as free software.

如果您希望代码进入主线内核，或者您的代码需要内核补丁，则必须在发布代码后立即使用 GPL 兼容许可证。尽管个人使用您的更改不会将 GPL 强加给您，但如果您分发代码，则必须在分发中包含源代码 - 必须允许获取您的软件包的人随意重建二进制文件。

If you want your code to go into the mainline kernel, or if your code requires patches to the kernel, you must use a GPL-compatible license as soon as you release the code. Although personal use of your changes doesn't force the GPL on you, if you distribute your code, you must include the source code in the distribution—people acquiring your package must be allowed to rebuild the binary at will.

就本书而言，大部分代码都可以自由地重新分发，无论是源代码还是二进制形式，我们和 O'Reilly 都不保留对任何派生作品的任何权利。所有程序都可以在ftp://ftp.ora.com/pub/examples/linux/drivers/上找到，确切的许可条款在同一目录中的LICENSE文件中说明。

As far as this book is concerned, most of the code is freely redistributable, either in source or binary form, and neither we nor O'Reilly retain any right on any derived works. All the programs are available at ftp://ftp.ora.com/pub/examples/linux/drivers/, and the exact license terms are stated in the LICENSE file in the same directory.

当您开始为以下内容编写模块时 Linux 内核，您将成为更大的开发人员社区的一部分。在这个社区中，您不仅可以找到从事类似工作的人员，还可以找到一群高度敬业的工程师，致力于使 Linux 成为一个更好的系统。这些人也可以成为帮助、想法和批判性评论的来源——当您为新驱动程序寻找测试人员时，他们可能是您首先会求助的人。

As you begin writing modules for the Linux kernel, you become part of a larger community of developers. Within that community, you can find not only people engaged in similar work, but also a group of highly committed engineers working toward making Linux a better system. These people can be a source of help, ideas, and critical review as well—they will be the first people you will likely turn to when you are looking for testers for a new driver.

Linux 内核开发人员的中心聚集点是 linux-kernel邮件列表。所有主要的内核开发人员，从 Linus Torvalds 开始，都订阅了这个列表。请注意，该列表不适合胆小的人：截至撰写本文时，流量每天最多可达 200 条消息或更多。尽管如此，对于那些对内核开发感兴趣的人来说，遵循这个列表是必不可少的；对于那些需要内核开发帮助的人来说，它也可以成为优质资源。

The central gathering point for Linux kernel developers is the linux-kernel mailing list. All major kernel developers, from Linus Torvalds on down, subscribe to this list. Please note that the list is not for the faint of heart: traffic as of this writing can run up to 200 messages per day or more. Nonetheless, following this list is essential for those who are interested in kernel development; it also can be a top-quality resource for those in need of kernel development help.

要加入 linux-kernel 列表，请按照 linux-kernel 邮件列表常见问题解答中的说明进行操作： http: //www.tux.org/lkml。阅读常见问题解答的其余部分；那里有大量有用的信息。Linux 内核开发人员都是忙碌的人，他们更倾向于帮助那些首先明确完成作业的人。

To join the linux-kernel list, follow the instructions found in the linux-kernel mailing list FAQ: http://www.tux.org/lkml. Read the rest of the FAQ while you are at it; there is a great deal of useful information there. Linux kernel developers are busy people, and they are much more inclined to help people who have clearly done their homework first.

从这里开始，我们进入了内核编程的世界。第 2 章介绍了模块化，解释了该技术的秘密并展示了运行模块的代码。第 3 章讨论了字符驱动程序，并展示了基于内存的设备驱动程序的完整代码，该驱动程序可以有趣地读写。使用内存作为设备的硬件基础，任何人都可以运行示例代码，而无需获取特殊硬件。

From here on, we enter the world of kernel programming. Chapter 2 introduces modularization, explaining the secrets of the art and showing the code for running modules. Chapter 3 talks about char drivers and shows the complete code for a memory-based device driver that can be read and written for fun. Using memory as the hardware base for the device allows anyone to run the sample code without the need to acquire special hardware.

调试技术是程序员的重要工具，将在第 4 章中介绍。对于那些想要破解当代内核的人来说，同样重要的是并发和竞争条件的管理。第5章关注并发访问资源所带来的问题，并介绍Linux控制并发的机制。

Debugging techniques are vital tools for the programmer and are introduced in Chapter 4. Equally important for those who would hack on contemporary kernels is the management of concurrency and race conditions. Chapter 5 concerns itself with the problems posed by concurrent access to resources and introduces the Linux mechanisms for controlling concurrency.

掌握了调试和并发管理技能后，我们将转向 char 驱动程序的高级功能，例如阻塞操作、 select的使用以及重要的ioctl调用；这些主题是第 6 章的主题。

With debugging and concurrency management skills in place, we move to advanced features of char drivers, such as blocking operations, the use of select, and the important ioctl call; these topics are the subject of Chapter 6.

在讨论硬件管理之前，我们先剖析一些内核的软件接口：第 7 章展示了内核中如何管理时间，第 8 章解释了内存分配。

Before dealing with hardware management, we dissect a few more of the kernel's software interfaces: Chapter 7 shows how time is managed in the kernel, and Chapter 8 explains memory allocation.

接下来我们重点关注硬件。第 9 章描述了设备上 I/O 端口和内存缓冲区的管理；之后是第 10 章中的中断处理。不幸的是，并不是每个人都能运行这些章节的示例代码，因为实际上需要一些硬件支持来测试软件接口中断。我们已尽力将所需的硬件支持保持在最低限度，但您仍然需要一些简单的硬件（例如标准并行端口）来使用这些章节的示例代码。

Next we focus on hardware. Chapter 9 describes the management of I/O ports and memory buffers that live on the device; after that comes interrupt handling, in Chapter 10. Unfortunately, not everyone is able to run the sample code for these chapters, because some hardware support is actually needed to test the software interface interrupts. We've tried our best to keep required hardware support to a minimum, but you still need some simple hardware, such as a standard parallel port, to work with the sample code for these chapters.

第11章介绍了内核中数据类型的使用以及可移植代码的编写。

Chapter 11 covers the use of data types in the kernel and the writing of portable code.

本书的后半部分致力于更高级的主题。我们首先深入了解硬件，特别是特定外设总线的功能。 第 12 章介绍了为 PCI 设备编写驱动程序的详细信息，第 13 章介绍了使用 USB 设备的 API。

The second half of the book is dedicated to more advanced topics. We start by getting deeper into the hardware and, in particular, the functioning of specific peripheral buses. Chapter 12 covers the details of writing drivers for PCI devices, and Chapter 13 examines the API for working with USB devices.

了解了外围总线后，我们可以详细了解 Linux 设备模型，它是内核用来描述其管理的硬件和软件资源的抽象层。第14章是对设备模型基础设施的自下而上的观察，从kobject类型开始并从那里开始工作。它涵盖了设备模型与真实硬件的集成；然后，它利用这些知识来涵盖热插拔设备和电源管理等主题。

With an understanding of peripheral buses in place, we can take a detailed look at the Linux device model, which is the abstraction layer used by the kernel to describe the hardware and software resources it is managing. Chapter 14 is a bottom-up look at the device model infrastructure, starting with the kobject type and working up from there. It covers the integration of the device model with real hardware; it then uses that knowledge to cover topics like hot-pluggable devices and power management.

在第 15 章中，我们将转向 Linux 内存管理。本章介绍如何将内核内存映射到用户空间（ mmap系统调用），将用户内存映射到内核空间（使用 get_user_pages），以及如何将任一类型的内存映射到设备空间（以执行直接内存访问 [DMA] 操作）。

In Chapter 15, we take a diversion into Linux memory management. This chapter shows how to map kernel memory into user space (the mmap system call), map user memory into kernel space (with get_user_pages), and how to map either kind of memory into device space (to perform direct memory access [DMA] operations).

我们对内存的理解对于接下来的两章很有用，它们涵盖了其他主要的驱动程序类。第 16 章 介绍了块驱动程序，并展示了它们与我们迄今为止使用过的字符驱动程序的不同之处。然后第 17 章开始讨论网络驱动程序的编写。我们最后讨论了串行驱动程序和参考书目。

Our understanding of memory will be useful for the following two chapters, which cover the other major driver classes. Chapter 16 introduces block drivers and shows how they are different from the char drivers we have worked with so far. Then Chapter 17 gets into the writing of network drivers. We finish up with a discussion of serial drivers and a bibliography.

从本章开始，我们 提供示例模块来演示编程概念。（所有这些示例都可以在 O'Reilly 的 FTP 站点上找到，如第 1 章中所述。）构建、加载和修改这些示例是加深您对驱动程序如何工作以及与内核交互的理解的好方法。

Starting with this chapter, we present example modules to demonstrate programming concepts. (All of these examples are available on O'Reilly's FTP site, as explained in Chapter 1.) Building, loading, and modifying these examples are a good way to improve your understanding of how drivers work and interact with the kernel.

示例模块应该适用于几乎所有 2.6.x 内核，包括发行版供应商提供的内核。但是，我们建议您直接从以下位置获取“主线”内核 kernel.org镜像网络，并将其安装到您的系统上。供应商内核可以进行大量修补并且与主线不同；有时，供应商补丁可以更改设备驱动程序所看到的内核 API。如果您正在编写必须在特定发行版上运行的驱动程序，您肯定会希望针对相关内核进行构建和测试。但是，为了学习驱动程序编写，标准内核是最好的。

The example modules should work with almost any 2.6.x kernel, including those provided by distribution vendors. However, we recommend that you obtain a "mainline" kernel directly from the kernel.org mirror network, and install it on your system. Vendor kernels can be heavily patched and divergent from the mainline; at times, vendor patches can change the kernel API as seen by device drivers. If you are writing a driver that must work on a particular distribution, you will certainly want to build and test against the relevant kernels. But, for the purpose of learning about driver writing, a standard kernel is best.

无论内核的来源如何，构建 2.6.x 的模块都要求您在系统上配置并构建内核树。此要求是对以前版本内核的更改，其中当前的头文件集就足够了。2.6 模块与内核源代码树中找到的目标文件链接；结果是一个更强大的模块加载器，但也要求这些目标文件可用。因此，您的首要任务是提出一个内核源代码树（来自 kernel.org网络或您的发行商的内核源代码包），构建一个新内核，并将其安装在您的系统上。由于我们稍后会看到的原因，如果您在构建模块时实际运行目标内核，那么生活通常是最简单的，尽管这不是必需的。

Regardless of the origin of your kernel, building modules for 2.6.x requires that you have a configured and built kernel tree on your system. This requirement is a change from previous versions of the kernel, where a current set of header files was sufficient. 2.6 modules are linked against object files found in the kernel source tree; the result is a more robust module loader, but also the requirement that those object files be available. So your first order of business is to come up with a kernel source tree (either from the kernel.org network or your distributor's kernel source package), build a new kernel, and install it on your system. For reasons we'll see later, life is generally easiest if you are actually running the target kernel when you build your modules, though this is not required.

因此，如果您还没有合适的系统在磁盘上配置和构建内核源代码树，那么现在是进行设置的好时机。我们会等待。一旦完成该任务，您就可以开始使用内核模块了。

So, if you do not yet have a suitable system with a configured and built kernel source tree on disk, now would be a good time to set that up. We'll wait. Once that task is taken care of, you'll be ready to start playing with kernel modules.

许多编程书籍开始 以“hello world”示例作为展示最简单的程序的方式。本书讨论的是内核模块而不是程序；因此，对于不耐烦的读者来说，以下代码是一个完整的“hello world”模块：

Many programming books begin with a "hello world" example as a way of showing the simplest possible program. This book deals in kernel modules rather than programs; so, for the impatient reader, the following code is a complete "hello world" module:

#include <linux/init.h>
#include <linux/module.h>
MODULE_LICENSE("双 BSD/GPL");

静态 int hello_init(void)
{
    printk(KERN_ALERT "你好，世界\n");
    返回0；
}

静态无效hello_exit（无效）
{
    printk(KERN_ALERT "再见，残酷的世界\n");
}

module_init(hello_init);
module_exit(hello_exit);

#include <linux/init.h>
#include <linux/module.h>
MODULE_LICENSE("Dual BSD/GPL");

static int hello_init(void)
{
    printk(KERN_ALERT "Hello, world\n");
    return 0;
}

static void hello_exit(void)
{
    printk(KERN_ALERT "Goodbye, cruel world\n");
}

module_init(hello_init);
module_exit(hello_exit);

该模块定义了两个 函数，一个在模块加载到内核时调用（hello_init），另一个在模块删除时调用（hello_exit）。module_init和 module_exit行使用特殊的内核宏来指示这两个函数的作用。另一个特殊的宏（MODULE_LICENSE）用于告诉内核该模块拥有免费许可证；如果没有这样的声明，内核在加载模块时会发出抱怨。

This module defines two functions, one to be invoked when the module is loaded into the kernel (hello_init) and one for when the module is removed (hello_exit). The module_init and module_exit lines use special kernel macros to indicate the role of these two functions. Another special macro (MODULE_LICENSE) is used to tell the kernel that this module bears a free license; without such a declaration, the kernel complains when the module is loaded.

打印k 函数在 Linux 内核中定义并可供模块使用；它的行为类似于标准 C 库函数printf。内核需要自己的打印功能，因为它自己运行，不需要C库的帮助。该模块可以调用 printk，因为在insmod加载它之后，该模块链接到内核并可以访问内核的公共符号（函数和变量，如下一节详细介绍）。该字符串KERN_ALERT是消息的优先级。^{[ 1 ]}我们在此模块中指定了高优先级，因为具有默认优先级的消息可能不会显示在任何有用的地方，具体取决于您正在运行的内核版本、 klogd的版本 守护进程和您的配置。您暂时可以忽略这个问题；我们将在第 4 章中对其进行解释。

The printk function is defined in the Linux kernel and made available to modules; it behaves similarly to the standard C library function printf. The kernel needs its own printing function because it runs by itself, without the help of the C library. The module can call printk because, after insmod has loaded it, the module is linked to the kernel and can access the kernel's public symbols (functions and variables, as detailed in the next section). The string KERN_ALERT is the priority of the message.^[1] We've specified a high priority in this module, because a message with the default priority might not show up anywhere useful, depending on the kernel version you are running, the version of the klogd daemon, and your configuration. You can ignore this issue for now; we explain it in Chapter 4.

您可以使用insmod测试该模块 和 rmmod实用程序，如下所示。请注意，只有超级用户可以加载和卸载模块。

You can test the module with the insmod and rmmod utilities, as shown below. Note that only the superuser can load and unload a module.

%make
make[1]: 进入目录 `/usr/src/linux-2.6.10'
  抄送 [M] /home/ldd3/src/misc-modules/hello.o
  构建模块，第 2 阶段。
  模块化邮政
  CC /home/ldd3/src/misc-modules/hello.mod.o
  LD [M] /home/ldd3/src/misc-modules/hello.ko
make[1]: 离开目录 `/usr/src/linux-2.6.10'
%su
根#insmod ./hello.ko
你好世界
根＃rmmod hello
再见残酷的世界
根＃

% make
make[1]: Entering directory `/usr/src/linux-2.6.10'
  CC [M]  /home/ldd3/src/misc-modules/hello.o
  Building modules, stage 2.
  MODPOST
  CC      /home/ldd3/src/misc-modules/hello.mod.o
  LD [M]  /home/ldd3/src/misc-modules/hello.ko
make[1]: Leaving directory `/usr/src/linux-2.6.10'
% su
root# insmod ./hello.ko
Hello, world
root# rmmod hello
Goodbye cruel world
root#

请再次注意，要使上述命令序列起作用，您必须在 makefile 能够找到它的位置（示例中为 /usr/src/linux-2.6.10）正确配置和构建内核树所示）。我们在2.4 节中详细介绍了如何构建模块。

Please note once again that, for the above sequence of commands to work, you must have a properly configured and built kernel tree in a place where the makefile is able to find it (/usr/src/linux-2.6.10 in the example shown). We get into the details of how modules are built in Section 2.4.

根据您的系统用于传递消息行的机制，您的输出可能会有所不同。特别是，之前的屏幕转储是从文本控制台获取的；如果您从在窗口系统下运行的终端仿真器运行insmod和rmmod，您将不会在屏幕上看到任何内容。该消息将发送到系统日志文件之一，例如/var/log/messages（实际文件的名称因 Linux 发行版而异）。用于交付的机制 内核消息在第 4 章中描述。

According to the mechanism your system uses to deliver the message lines, your output may be different. In particular, the previous screen dump was taken from a text console; if you are running insmod and rmmod from a terminal emulator running under the window system, you won't see anything on your screen. The message goes to one of the system log files, such as /var/log/messages (the name of the actual file varies between Linux distributions). The mechanism used to deliver kernel messages is described in Chapter 4.

正如您所看到的，编写模块并不像您想象的那么困难——至少，只要模块不需要做任何有价值的事情。困难的部分是了解您的设备以及如何最大限度地提高性能。我们在整个过程中更深入地探讨了模块化 章节并将特定于设备的问题留给后面的章节。

As you can see, writing a module is not as difficult as you might expect—at least, as long as the module is not required to do anything worthwhile. The hard part is understanding your device and how to maximize performance. We go deeper into modularization throughout this chapter and leave device-specific issues for later chapters.

在我们进一步讨论之前，值得 强调内核模块和应用程序之间的各种差异。

Before we go further, it's worth underlining the various differences between a kernel module and an application.

虽然大多数中小型应用程序从头到尾执行单个任务，但每个内核模块只是注册自己以服务将来的请求，并且其初始化函数立即终止。换句话说，模块的初始化函数的任务是为以后调用模块的函数做准备；就好像该模块在说：“我在这里，这就是我能做的。” 模块的退出函数（hello_exit在示例中）在模块卸载之前被调用。它应该告诉内核，“我已经不在那里了；不要要求我做任何其他事情。” 这种编程方法类似于事件驱动编程，但虽然并非所有应用程序都是事件驱动的，但每个内核模块都是事件驱动的。事件驱动应用程序和内核代码之间的另一个主要区别在于退出函数：虽然终止的应用程序可能会懒惰地释放资源或完全避免清理，但模块的退出函数必须小心地撤消 init 函数构建的所有 内容，或者这些碎片会保留下来，直到系统重新启动。

While most small and medium-sized applications perform a single task from beginning to end, every kernel module just registers itself in order to serve future requests, and its initialization function terminates immediately. In other words, the task of the module's initialization function is to prepare for later invocation of the module's functions; it's as though the module were saying, "Here I am, and this is what I can do." The module's exit function (hello_exit in the example) gets invoked just before the module is unloaded. It should tell the kernel, "I'm not there anymore; don't ask me to do anything else." This kind of approach to programming is similar to event-driven programming, but while not all applications are event-driven, each and every kernel module is. Another major difference between event-driven applications and kernel code is in the exit function: whereas an application that terminates can be lazy in releasing resources or avoids clean up altogether, the exit function of a module must carefully undo everything the init function built up, or the pieces remain around until the system is rebooted.

顺便说一句，卸载模块的能力是您最欣赏的模块化功能之一，因为它有助于缩短开发时间；您可以测试新驱动程序的连续版本，而无需每次都经历漫长的关闭/重新启动周期。

Incidentally, the ability to unload a module is one of the features of modularization that you'll most appreciate, because it helps cut down development time; you can test successive versions of your new driver without going through the lengthy shutdown/reboot cycle each time.

作为程序员，您知道应用程序可以调用它未定义的函数：链接阶段使用适当的函数库解析外部引用。printf是这些可调用函数之一，在libc中定义。另一方面，模块仅链接到内核，并且它唯一可以调用的是内核导出的函数；没有可链接的库。例如，之前hello.c中使用的printk函数 是在内核中定义并导出到模块的printf 版本。它的行为与原始函数类似，但有一些细微的差异，主要的差异是缺乏浮点支持。

As a programmer, you know that an application can call functions it doesn't define: the linking stage resolves external references using the appropriate library of functions. printf is one of those callable functions and is defined in libc. A module, on the other hand, is linked only to the kernel, and the only functions it can call are the ones exported by the kernel; there are no libraries to link to. The printk function used in hello.c earlier, for example, is the version of printf defined within the kernel and exported to modules. It behaves similarly to the original function, with a few minor differences, the main one being lack of floating-point support.

图 2-1显示了如何在模块中使用函数调用和函数指针来向正在运行的内核添加新功能。

Figure 2-1 shows how function calls and function pointers are used in a module to add new functionality to a running kernel.

图 2-1。将模块链接到内核

Figure 2-1. Linking a module to the kernel

由于没有库链接到模块，因此源文件不应包含通常的头文件<stdarg.h>，非常特殊的情况是唯一的例外。只有实际上属于内核本身一部分的函数才可以在内核模块中使用。与内核相关的任何内容都在您已设置和配置的内核源代码树中找到的标头中声明；大多数相关头文件位于include/linux和include/asm中，但include的其他子目录已添加到与特定内核子系统相关的主机材料中。

Because no library is linked to modules, source files should never include the usual header files, <stdarg.h> and very special situations being the only exceptions. Only functions that are actually part of the kernel itself may be used in kernel modules. Anything related to the kernel is declared in headers found in the kernel source tree you have set up and configured; most of the relevant headers live in include/linux and include/asm, but other subdirectories of include have been added to host material associated to specific kernel subsystems.

本书中介绍了各个内核头文件的作用，因为每个内核头文件都是需要的。

The role of individual kernel headers is introduced throughout the book as each of them is needed.

内核编程和应用程序编程之间的另一个重要区别在于每个环境如何处理 错误：虽然分段错误在应用程序开发过程中是无害的，并且始终可以使用调试器来跟踪源代码中的问题，但内核错误至少会杀死当前进程（如果不是整个系统）。我们将在第 4 章中了解如何跟踪内核错误。

Another important difference between kernel programming and application programming is in how each environment handles faults: whereas a segmentation fault is harmless during application development and a debugger can always be used to trace the error to the problem in the source code, a kernel fault kills the current process at least, if not the whole system. We see how to trace kernel errors in Chapter 4.

printk(KERN_INFO "进程是 \"%s\" (pid %i)\n",
        当前->comm，当前->pid);

printk(KERN_INFO "The process is \"%s\" (pid %i)\n",
        current->comm, current->pid);

本章开头的“hello world”示例包括构建模块并将其加载到系统中的简短演示。当然，整个过程的内容比我们迄今为止看到的要多得多。本节提供有关模块作者如何将源代码转换为内核中的执行子系统的更多详细信息。

The "hello world" example at the beginning of this chapter included a brief demonstration of building a module and loading it into the system. There is, of course, a lot more to that whole process than we have seen so far. This section provides more detail on how a module author turns source code into an executing subsystem within the kernel.

obj-m := 你好.o

obj-m := hello.o

obj-m := 模块.o
模块-objs := file1.o file2.o

obj-m := module.o
module-objs := file1.o file2.o

make -C ~/kernel-2.6 M=`pwd` 模块

make -C ~/kernel-2.6 M=`pwd` modules

# 如果定义了 KERNELRELEASE，我们就会被调用
# 内核构建系统并可以使用其语言。
ifneq ($(KERNELRELEASE),)
    obj-m := 你好.o

# 否则我们会直接从命令调用
＃ 线; 调用内核构建系统。
别的

    KERNELDIR ?= /lib/modules/$(shell uname -r)/build
    PWD := $(shell 密码)

默认：
    $(MAKE) -C $(KERNELDIR) M=$(PWD) 模块

万一

# If KERNELRELEASE is defined, we've been invoked from the
# kernel build system and can use its language.
ifneq ($(KERNELRELEASE),)
    obj-m := hello.o 

# Otherwise we were called directly from the command
# line; invoke the kernel build system.
else

    KERNELDIR ?= /lib/modules/$(shell uname -r)/build
    PWD  := $(shell pwd)

default:
    $(MAKE) -C $(KERNELDIR) M=$(PWD) modules

endif

#insmod hello.ko
插入 './hello.ko' 时出错：-1 模块格式无效

# insmod hello.ko
Error inserting './hello.ko': -1 Invalid module format

我们已经看到了insmod如何解决 公共内核符号表中未定义的符号。该表包含实现模块化驱动程序所需的全局内核项（函数和变量）的地址。当加载模块时，该模块导出的任何符号都会成为内核符号表的一部分。在通常情况下，模块实现自己的功能，根本不需要导出任何符号。但是，只要其他模块可以从使用符号中受益，您就需要导出符号。

We've seen how insmod resolves undefined symbols against the table of public kernel symbols. The table contains the addresses of global kernel items—functions and variables—that are needed to implement modularized drivers. When a module is loaded, any symbol exported by the module becomes part of the kernel symbol table. In the usual case, a module implements its own functionality without the need to export any symbols at all. You need to export symbols, however, whenever other modules may benefit from using them.

新模块可以使用模块导出的符号，并且您可以将新模块堆叠在其他模块之上。主流内核源代码中也实现了模块堆栈：msdos文件系统依赖于fat模块导出的符号，每个输入 USB 设备模块堆栈在usbcore和输入模块上。

New modules can use symbols exported by your module, and you can stack new modules on top of other modules. Module stacking is implemented in the mainstream kernel sources as well: the msdos filesystem relies on symbols exported by the fat module, and each input USB device module stacks on the usbcore and input modules.

模块堆叠很有用 复杂的项目。如果一个新的抽象以设备驱动程序的形式实现，它可能会为特定于硬件的实现提供一个插件。例如，video-for-linux 驱动程序集被分成一个通用模块，该模块导出特定硬件的较低级别设备驱动程序使用的符号。根据您的设置，您可以加载通用视频模块和适用于已安装硬件的特定模块。对并行端口和各种可连接设备的支持以相同的方式处理，USB 内核子系统也是如此。并行端口子系统中的堆栈是如图2-2所示 ；箭头显示模块之间以及与内核编程接口的通信。

Module stacking is useful in complex projects. If a new abstraction is implemented in the form of a device driver, it might offer a plug for hardware-specific implementations. For example, the video-for-linux set of drivers is split into a generic module that exports symbols used by lower-level device drivers for specific hardware. According to your setup, you load the generic video module and the specific module for your installed hardware. Support for parallel ports and the wide variety of attachable devices is handled in the same way, as is the USB kernel subsystem. Stacking in the parallel port subsystem is shown in Figure 2-2; the arrows show the communications between the modules and with the kernel programming interface.

图 2-2。并行端口驱动器模块的堆叠

Figure 2-2. Stacking of parallel port driver modules

当使用堆叠模块时，了解 modprobe很有帮助 公用事业。正如我们之前所描述的，modprobe 的功能与insmod大致相同 ，但它还加载您要加载的模块所需的任何其他模块。因此，一个modprobe命令有时可以替代对insmod的多次调用（尽管从当前目录加载您自己的模块时仍然需要 insmod ，因为modprobe仅在标准安装的模块目录中查找）。

When using stacked modules, it is helpful to be aware of the modprobe utility. As we described earlier, modprobe functions in much the same way as insmod, but it also loads any other modules that are required by the module you want to load. Thus, one modprobe command can sometimes replace several invocations of insmod (although you'll still need insmod when loading your own modules from the current directory, because modprobe looks only in the standard installed module directories).

使用堆栈将模块分成多个层可以通过简化每一层来帮助减少开发时间。这类似于我们在第一章中讨论的机制和策略的分离。

Using stacking to split modules into multiple layers can help reduce development time by simplifying each layer. This is similar to the separation between mechanism and policy that we discussed in Chapter 1.

Linux 内核头文件提供了一种管理符号可见性的便捷方法，从而减少命名空间污染（使用可能与内核其他地方定义的名称冲突的名称填充命名空间）并促进正确的信息隐藏。如果您的模块需要导出供其他模块使用的符号，应使用以下宏。

The Linux kernel header files provide a convenient way to manage the visibility of your symbols, thus reducing namespace pollution (filling the namespace with names that may conflict with those defined elsewhere in the kernel) and promoting proper information hiding. If your module needs to export symbols for other modules to use, the following macros should be used.

EXPORT_SYMBOL（名称）；
EXPORT_SYMBOL_GPL(名称);

EXPORT_SYMBOL(name);
EXPORT_SYMBOL_GPL(name);

上述任一宏都使给定符号在模块外部可用。该 _GPL版本使该符号仅可用于 GPL 许可的模块。符号必须在模块文件的全局部分（任何函数之外）中导出，因为宏会扩展为可全局访问的特殊用途变量的声明。该变量存储在模块可执行文件的一个特殊部分（“ELF 部分”）中，内核在加载时使用该部分来查找模块导出的变量。（有兴趣的读者可以查看<linux/module.h>了解详细信息，尽管不需要详细信息 让事情顺利进行。）

Either of the above macros makes the given symbol available outside the module. The _GPL version makes the symbol available to GPL-licensed modules only. Symbols must be exported in the global part of the module's file, outside of any function, because the macros expand to the declaration of a special-purpose variable that is expected to be accessible globally. This variable is stored in a special part of the module executible (an "ELF section") that is used by the kernel at load time to find the variables exported by the module. (Interested readers can look at <linux/module.h> for the details, even though the details are not needed to make things work.)

我们越来越接近寻找 在一些实际的模块代码中。但首先，我们需要看看需要出现在模块源文件中的其他一些内容。内核是一个独特的环境，它对与其交互的代码提出了自己的要求。

We are getting closer to looking at some actual module code. But first, we need to look at some other things that need to appear in your module source files. The kernel is a unique environment, and it imposes its own requirements on code that would interface with it.

大多数内核代码最终都会包含相当多的头文件来获取函数、数据类型和变量的定义。我们将在接触这些文件时检查它们，但有一些文件是特定于模块的，并且必须出现在每个可加载模块中。因此，几乎所有模块代码都具有以下内容：

Most kernel code ends up including a fairly large number of header files to get definitions of functions, data types, and variables. We'll examine these files as we come to them, but there are a few that are specific to modules, and must appear in every loadable module. Thus, just about all module code has the following:

#include <linux/module.h>
#include <linux/init.h>

#include <linux/module.h>
#include <linux/init.h>

module.h包含可加载模块所需的符号和函数的大量定义。您需要init.h来指定初始化和清理函数，正如我们在上面的“hello world”示例中看到的那样，我们将在下一节中重新讨论它。大多数模块还包含moduleparam.h以允许在加载时向模块传递参数；我们很快就会讨论这个问题。

module.h contains a great many definitions of symbols and functions needed by loadable modules. You need init.h to specify your initialization and cleanup functions, as we saw in the "hello world" example above, and which we revisit in the next section. Most modules also include moduleparam.h to enable the passing of parameters to the module at load time; we will get to that shortly.

这并不是绝对必要的，但您的模块确实应该指定哪个许可证适用于其代码。这样做只需包含一行MODULE_LICENSE：

It is not strictly necessary, but your module really should specify which license applies to its code. Doing so is just a matter of including a MODULE_LICENSE line:

MODULE_LICENSE(“GPL”);

MODULE_LICENSE("GPL");

内核识别的具体许可证有“GPL”（适用于任何版本的 GNU 通用公共许可证）、“GPL v2”（仅适用于 GPL 版本二）、“GPL 和附加权利”、“双 BSD/GPL”、“双 MPL/GPL”和“专有”。除非您的模块被明确标记为处于内核识别的免费许可证之下，否则它被认为是专有的，并且在加载模块时内核会被“污染”。正如我们在1.6 节中提到的，内核开发人员往往不热衷于帮助在加载专有模块后遇到问题的用户。

The specific licenses recognized by the kernel are "GPL" (for any version of the GNU General Public License), "GPL v2" (for GPL version two only), "GPL and additional rights," "Dual BSD/GPL," "Dual MPL/GPL," and "Proprietary." Unless your module is explicitly marked as being under a free license recognized by the kernel, it is assumed to be proprietary, and the kernel is "tainted" when the module is loaded. As we mentioned in Section 1.6, kernel developers tend to be unenthusiastic about helping users who experience problems after loading proprietary modules.

模块中可以包含的其他描述性定义包括MODULE_AUTHOR（说明模块的编写者）、MODULE_DESCRIPTION（模块功能的人类可读声明）、MODULE_VERSION（代码修订号；请参阅<linux/module.h>中的注释用于创建版本字符串时使用的约定），MODULE_ALIAS（可以知道该模块的另一个名称），以及MODULE_DEVICE_TABLE（告诉用户空间该模块支持哪些设备）。

Other descriptive definitions that can be contained within a module include MODULE_AUTHOR (stating who wrote the module), MODULE_DESCRIPTION (a human-readable statement of what the module does), MODULE_VERSION (for a code revision number; see the comments in <linux/module.h> for the conventions to use in creating version strings), MODULE_ALIAS (another name by which this module can be known), and MODULE_DEVICE_TABLE (to tell user space about which devices the module supports).

各种MODULE_声明可以出现在源文件中函数之外的任何位置。然而，内核代码中相对较新的约定是将这些声明放在文件末尾。

The various MODULE_ declarations can appear anywhere within your source file outside of a function. A relatively recent convention in kernel code, however, is to put these declarations at the end of the file.

正如已经提到的，该模块 初始化函数注册模块提供的任何设施。通过 设施，我们指的是可以由应用程序访问的新功能，无论是整个驱动程序还是新的软件抽象。初始化函数的实际定义总是如下所示：

As already mentioned, the module initialization function registers any facility offered by the module. By facility, we mean a new functionality, be it a whole driver or a new software abstraction, that can be accessed by an application. The actual definition of the initialization function always looks like:

static int __init 初始化函数(void)
{
    /* 初始化代码在这里 */
}
module_init(初始化函数);

static int _ _init initialization_function(void)
{
    /* Initialization code here */
}
module_init(initialization_function);

应该声明初始化函数static，因为它们在特定文件之外不可见；不过，对此没有硬性规则，因为除非明确请求，否则不会将任何函数导出到内核的其余部分。定义中的token_ _init可能看起来有点奇怪；它向内核暗示给定的函数仅在初始化时使用。模块加载器在模块加载后删除初始化函数，使其内存可供其他用途。对于仅在初始化期间使用的数据，有一个类似的标签 ( _ _initdata)。使用 _ _init和_ _initdata是可选的，但值得麻烦。请确保不要将它们用于初始化完成后将使用的任何函数（或数据结构）。您可能还会在内核源代码中遇到_ _devinitand ；仅当内核尚未配置为可热插拔设备时，_ _devinitdata这些才会转换。我们将在第 14 章讨论热插拔支持。_ _init_ _initdata

Initialization functions should be declared static, since they are not meant to be visible outside the specific file; there is no hard rule about this, though, as no function is exported to the rest of the kernel unless explicitly requested. The _ _init token in the definition may look a little strange; it is a hint to the kernel that the given function is used only at initialization time. The module loader drops the initialization function after the module is loaded, making its memory available for other uses. There is a similar tag (_ _initdata) for data used only during initialization. Use of _ _init and _ _initdata is optional, but it is worth the trouble. Just be sure not to use them for any function (or data structure) you will be using after initialization completes. You may also encounter _ _devinit and _ _devinitdata in the kernel source; these translate to _ _init and _ _initdata only if the kernel has not been configured for hotpluggable devices. We will look at hotplug support in Chapter 14.

module_init的使用 是强制性的。该宏向模块的目标代码添加一个特殊部分，说明在哪里可以找到模块的初始化函数。如果没有这个定义，你的初始化函数就永远不会被调用。

The use of module_init is mandatory. This macro adds a special section to the module's object code stating where the module's initialization function is to be found. Without this definition, your initialization function is never called.

模块可以注册许多不同类型的设施，包括不同类型的设备、文件系统、加密转换等等。对于每个设施，都有一个特定的内核函数来完成此注册。传递给内核注册函数的参数通常是指向描述新设施和正在注册的设施名称的数据结构的指针。数据结构通常包含指向模块函数的指针，这就是调用模块主体中的函数的方式。

Modules can register many different types of facilities, including different kinds of devices, filesystems, cryptographic transforms, and more. For each facility, there is a specific kernel function that accomplishes this registration. The arguments passed to the kernel registration functions are usually pointers to data structures describing the new facility and the name of the facility being registered. The data structure usually contains pointers to module functions, which is how functions in the module body get called.

可以注册的项目超出了第 1 章中提到的设备类型列表。其中包括串行端口、杂项设备、sysfs 条目、/proc文件、可执行域和行规则。许多可注册项目支持与硬件不直接相关的功能，但仍保留在“软件抽象”领域。这些项目可以注册，因为它们无论如何都集成到驱动程序的功能中（例如/proc文件和行规则）。

The items that can be registered go beyond the list of device types mentioned in Chapter 1. They include, among others, serial ports, miscellaneous devices, sysfs entries, /proc files, executable domains, and line disciplines. Many of those registrable items support functions that aren't directly related to hardware but remain in the "software abstractions" field. Those items can be registered, because they are integrated into the driver's functionality anyway (like /proc files and line disciplines for example).

还有其他功能可以注册为某些驱动程序的附加组件，但它们的用途非常具体，因此不值得讨论；他们使用堆叠技术，如第 2.5 节所述。EXPORT_SYMBOL如果您想进一步探究，您可以在内核源代码中进行grep 查找，并找到不同驱动程序提供的入口点。大多数注册函数都以 为前缀register_，因此找到它们的另一种可能方法是register_在内核源代码中 grep for 。

There are other facilities that can be registered as add-ons for certain drivers, but their use is so specific that it's not worth talking about them; they use the stacking technique, as described in Section 2.5. If you want to probe further, you can grep for EXPORT_SYMBOL in the kernel sources, and find the entry points offered by different drivers. Most registration functions are prefixed with register_, so another possible way to find them is to grep for register_ in the kernel source.

静态无效__退出cleanup_function（无效）
{
    /* 清理代码在这里 */
}

module_exit(cleanup_function);

static void _ _exit cleanup_function(void)
{
    /* Cleanup code here */
}

module_exit(cleanup_function);

int _ _init my_init_function(void)
{
    内部错误；

    /* 注册需要一个指针和一个名称 */
    err = register_this(ptr1, "头骨");
    如果（错误）转到fail_this；
    err = register_that(ptr2, "头骨");
    如果（错误）转到fail_that；
    err = register_those(ptr3, "头骨");
    如果（错误）转到fail_those；

    返回0；/* 成功 */

  fail_those: unregister_that(ptr2, "头骨");
  fail_that: unregister_this(ptr1, "头骨");
  fail_this：返回错误；/* 传播错误 */
 }

int _ _init my_init_function(void)
{
    int err;

    /* registration takes a pointer and a name */
    err = register_this(ptr1, "skull");
    if (err) goto fail_this;
    err = register_that(ptr2, "skull");
    if (err) goto fail_that;
    err = register_those(ptr3, "skull");
    if (err) goto fail_those;

    return 0; /* success */

  fail_those: unregister_that(ptr2, "skull");
  fail_that: unregister_this(ptr1, "skull");
  fail_this: return err; /* propagate the error */
 }

void _ _exit my_cleanup_function(void)
{
    unregister_those(ptr3, "头骨");
    unregister_that(ptr2, "头骨");
    unregister_this(ptr1, "头骨");
    返回;
}

void _ _exit my_cleanup_function(void)
{
    unregister_those(ptr3, "skull");
    unregister_that(ptr2, "skull");
    unregister_this(ptr1, "skull");
    return;
}

构造一些东西 *item1;
结构其他 *item2;
int stuff_ok；

无效 my_cleanup(无效)
{
    如果（第1项）
        release_thing(项目1);
    如果（第2项）
        release_thing2(项目2);
    如果（东西没问题）
        取消注册东西（）；
    返回;
 }

int _ _init my_init(void)
{
    int err = -ENOMEM;

    item1 = allocate_thing(参数);
    item2 = allocate_thing2(arguments2);
    if (!item2 || !item2)
        走向失败；
    错误 = register_stuff(item1, item2);
    如果（！错误）
        stuff_ok = 1;
    别的
        走向失败；
    返回0；/* 成功 */
   
  失败：
    我的清理（）；
    返回错误；
}

struct something *item1;
struct somethingelse *item2;
int stuff_ok;

void my_cleanup(void)
{
    if (item1)
        release_thing(item1);
    if (item2)
        release_thing2(item2);
    if (stuff_ok)
        unregister_stuff(  );
    return;
 }

int _ _init my_init(void)
{
    int err = -ENOMEM;

    item1 = allocate_thing(arguments);
    item2 = allocate_thing2(arguments2);
    if (!item2 || !item2)
        goto fail;
    err = register_stuff(item1, item2);
    if (!err)
        stuff_ok = 1;
    else
        goto fail;
    return 0; /* success */ 
   
  fail:
    my_cleanup(  );
    return err;
}

驱动程序需要的几个参数 知道可以根据系统的不同而改变。这些可能会有所不同，从要使用的设备编号（我们将在下一章中看到）到驱动程序应如何操作的许多方面。例如，SCSI 适配器的驱动程序通常具有控制标记命令队列的使用的选项，而集成设备电子 (IDE) 驱动程序允许用户控制 DMA 操作。如果您的驱动程序控制较旧的硬件，则可能还需要明确告知在哪里可以找到该硬件的 I/O 端口或 I/O 内存地址。内核通过使驱动程序能够指定在加载驱动程序模块时可能更改的参数来支持这些需求。

Several parameters that a driver needs to know can change from system to system. These can vary from the device number to use (as we'll see in the next chapter) to numerous aspects of how the driver should operate. For example, drivers for SCSI adapters often have options controlling the use of tagged command queuing, and the Integrated Device Electronics (IDE) drivers allow user control of DMA operations. If your driver controls older hardware, it may also need to be told explicitly where to find that hardware's I/O ports or I/O memory addresses. The kernel supports these needs by making it possible for a driver to designate parameters that may be changed when the driver's module is loaded.

这些参数值可以在加载时通​​过insmod或 modprobe分配；后者还可以从其配置文件（/etc/modprobe.conf）读取参数分配。这些命令接受命令行上多种类型值的规范。作为演示此功能的一种方式，想象一下本章开头所示的“hello world”模块（称为hellop ）急需的增强功能。我们添加两个参数：一个名为 的整数值howmany和一个名为 的字符串whom。那么，我们的功能模块在加载时whom不仅会打招呼一次，而且还会 打招呼。howmany次。然后可以使用命令行加载这样的模块，例如：

These parameter values can be assigned at load time by insmod or modprobe ; the latter can also read parameter assignment from its configuration file (/etc/modprobe.conf ). The commands accept the specification of several types of values on the command line. As a way of demonstrating this capability, imagine a much-needed enhancement to the "hello world" module (called hellop) shown at the beginning of this chapter. We add two parameters: an integer value called howmany and a character string called whom. Our vastly more functional module then, at load time, greets whom not just once, but howmany times. Such a module could then be loaded with a command line such as:

insmod hellop howmany=10 其中=“妈妈”

insmod hellop howmany=10 whom="Mom"

以这种方式加载后，hellop会说“你好，妈妈”10 次。

Upon being loaded that way, hellop would say "Hello, Mom" 10 times.

但是，在insmod可以更改模块参数之前，模块必须使它们可用。参数是用module_param宏声明的，该宏在moduleparam.h中定义。module_param 采用三个参数：变量的名称、变量的类型以及用于随附 sysfs 条目的权限掩码。宏应放置在任何函数之外，并且通常位于源文件的头部附近。因此，hellop将声明其参数并使它们可供insmod使用，如下所示：

However, before insmod can change module parameters, the module must make them available. Parameters are declared with the module_param macro, which is defined in moduleparam.h. module_param takes three parameters: the name of the variable, its type, and a permissions mask to be used for an accompanying sysfs entry. The macro should be placed outside of any function and is typically found near the head of the source file. So hellop would declare its parameters and make them available to insmod as follows:

静态字符*whom =“世界”;
静态 int 数量 = 1;
module_param(howmany, int, S_IRUGO);
module_param(whom,charp,S_IRUGO);

static char *whom = "world";
static int howmany = 1;
module_param(howmany, int, S_IRUGO);
module_param(whom, charp, S_IRUGO);

种类很多，有支持的模块参数：

Numerous types are supported for module parameters:

模块加载器还支持数组参数，其中值以逗号分隔的列表形式提供。到 声明一个数组参数，使用：

Array parameters, where the values are supplied as a comma-separated list, are also supported by the module loader. To declare an array parameter, use:

module_param_array(名称,类型,nump,perm);

module_param_array(name,type,nump,perm);

其中name是数组（和参数）的名称，type是数组元素的类型， nump是整型变量，perm是通常的权限值。如果在加载时设置数组参数，nump则设置为提供的值的数量。模块加载器拒绝接受超出数组容量的值。

Where name is the name of your array (and of the parameter), type is the type of the array elements, nump is an integer variable, and perm is the usual permissions value. If the array parameter is set at load time, nump is set to the number of values supplied. The module loader refuses to accept more values than will fit in the array.

如果您确实需要上面列表中没有出现的类型，则模块代码中有一些钩子允许您定义它们；有关如何执行此操作的详细信息，请参阅moduleparam.h 。所有模块参数都应该给一个默认值；仅当用户明确告知时，insmod才会更改值。该模块可以通过根据默认值测试参数来检查显式参数。

If you really need a type that does not appear in the list above, there are hooks in the module code that allow you to define them; see moduleparam.h for details on how to do that. All module parameters should be given a default value; insmod changes the value only if explicitly told to by the user. The module can check for explicit parameters by testing parameters against their default values.

最后的module_param字段是一个权限值；您应该使用<linux/stat.h>中的定义。该值控制谁可以访问 sysfs 中模块参数的表示形式。如果 perm设置为0，则根本没有 sysfs 条目；否则，它会出现在/sys/module ^{[ 3 ]}下，并具有给定的权限集。用于S_IRUGO外界可以读取但不能更改的参数； S_IRUGO|S_IWUSR允许 root 更改参数。请注意，如果 sysfs 更改了参数，则模块看到的该参数的值也会更改，但不会以任何其他方式通知您的模块。您可能不应该使模块参数可写，除非您准备好检测 改变并做出相应反应。

The final module_param field is a permission value; you should use the definitions found in <linux/stat.h>. This value controls who can access the representation of the module parameter in sysfs. If perm is set to 0, there is no sysfs entry at all; otherwise, it appears under /sys/module ^[3] with the given set of permissions. Use S_IRUGO for a parameter that can be read by the world but cannot be changed; S_IRUGO|S_IWUSR allows root to change the parameter. Note that if a parameter is changed by sysfs, the value of that parameter as seen by your module changes, but your module is not notified in any other way. You should probably not make module parameters writable, unless you are prepared to detect the change and react accordingly.

第一次解决内核问题的 Unix 程序员可能会对编写模块感到紧张。写作 直接读写设备端口的用户程序可能会更容易。

A Unix programmer who's addressing kernel issues for the first time might be nervous about writing a module. Writing a user program that reads and writes directly to the device ports may be easier.

事实上，有一些支持用户空间编程的论点，有时编写所谓的用户空间设备驱动程序是内核黑客的明智替代方案。在本节中，我们将讨论您可能在用户空间中编写驱动程序的一些原因。然而，本书是关于内核空间驱动程序的，因此我们不会超出这个介绍性讨论。

Indeed, there are some arguments in favor of user-space programming, and sometimes writing a so-called user-space device driver is a wise alternative to kernel hacking. In this section, we discuss some of the reasons why you might write a driver in user space. This book is about kernel-space drivers, however, so we do not go beyond this introductory discussion.

用户空间驱动程序的优点是：

The advantages of user-space drivers are:

例如，可以为用户空间编写USB驱动程序；请参阅 libusb.sourceforge.net 上的（仍然年轻的）libusb 项目和内核源代码中的“gadgetfs”。另一个例子是X服务器：它确切地知道硬件可以做什么和不能做什么，并且它向所有X客户端提供图形资源。但请注意，正在缓慢但稳定地转向基于帧缓冲区的图形环境，其中 X 服务器仅充当基于真实内核空间设备驱动程序的服务器，用于实际的图形操作。

For example, USB drivers can be written for user space; see the (still young) libusb project at libusb.sourceforge.net and "gadgetfs" in the kernel source. Another example is the X server: it knows exactly what the hardware can do and what it can't, and it offers the graphic resources to all X clients. Note, however, that there is a slow but steady drift toward frame-buffer-based graphics environments, where the X server acts only as a server based on a real kernel-space device driver for actual graphic manipulation.

通常，用户空间驱动程序的编写者会实现一个服务器进程，从内核接管作为负责硬件控制的单一代理的任务。然后，客户端应用程序可以连接到服务器以与设备执行实际通信；因此，智能驱动程序进程可以允许并发访问设备。这正是 X 服务器的工作原理。

Usually, the writer of a user-space driver implements a server process, taking over from the kernel the task of being the single agent in charge of hardware control. Client applications can then connect to the server to perform actual communication with the device; therefore, a smart driver process can allow concurrent access to the device. This is exactly how the X server works.

但用户空间的设备驱动方法有许多缺点。最重要的是：

But the user-space approach to device driving has a number of drawbacks. The most important are:

正如您所看到的，用户空间驱动程序毕竟不能做那么多事情。尽管如此，仍然存在一些有趣的应用程序：例如，对 SCSI 扫描仪设备（由 SANE包实现）和 CD 刻录机（由 cdrecord和其他工具实现）的支持。在这两种情况下，用户级设备驱动程序都依赖于“SCSI 通用”内核驱动程序，该驱动程序将低级 SCSI 功能导出到用户空间程序，以便它们可以驱动自己的硬件。

As you see, user-space drivers can't do that much after all. Interesting applications nonetheless exist: for example, support for SCSI scanner devices (implemented by the SANE package) and CD writers (implemented by cdrecord and other tools). In both cases, user-level device drivers rely on the "SCSI generic" kernel driver, which exports low-level SCSI functionality to user-space programs so they can drive their own hardware.

在用户空间中工作可能有意义的一种情况是当您开始处理新的和不寻常的硬件时。通过这种方式，您可以学习管理硬件，而无需担心整个系统挂起的风险。完成此操作后，将软件封装在内核模块中应该是一个简单的过程 无痛操作。

One case in which working in user space might make sense is when you are beginning to deal with new and unusual hardware. This way you can learn to manage your hardware without the risk of hanging the whole system. Once you've done that, encapsulating the software in a kernel module should be a painless operation.

本节总结了本章中涉及的内核函数、变量、宏和/proc文件。它的目的是作为参考。每个项目都列在相关头文件（如果有）之后。从现在开始，几乎每一章的末尾都会出现类似的部分，总结本章中引入的新符号。本节中的条目通常按照本章中介绍的顺序出现：

This section summarizes the kernel functions, variables, macros, and /proc files that we've touched on in this chapter. It is meant to act as a reference. Each item is listed after the relevant header file, if any. A similar section appears at the end of almost every chapter from here on, summarizing the new symbols introduced in the chapter. Entries in this section generally appear in the same order in which they were introduced in the chapter:

司机的第一步写作 定义驱动程序将提供给用户程序的功能（机制）。由于我们的“设备”是计算机内存的一部分，因此我们可以自由地用它做我们想做的事情。它可以是顺序或随机访问设备、一个或多个设备，等等。

The first step of driver writing is defining the capabilities (the mechanism) the driver will offer to user programs. Since our "device" is part of the computer's memory, we're free to do what we want with it. It can be a sequential or random-access device, one device or many, and so on.

为了使scull成为为真实设备编写真实驱动程序的模板，我们将向您展示如何在计算机内存之上实现多个设备抽象，每个抽象都有不同的个性。

To make scull useful as a template for writing real drivers for real devices, we'll show you how to implement several device abstractions on top of the computer memory, each with a different personality.

scull源实现了以下设备。模块实现的每种设备称为类型。

The scull source implements the following devices. Each kind of device implemented by the module is referred to as a type .

每个scull设备都展示了驱动程序的不同功能并提出了不同的困难。本章涵盖 scull0到scull3的内部结构；第 6 章介绍了更高级的设备。 scullpipe在第 3.4节中描述，其他在 第 6.6 节中描述

Each of the scull devices demonstrates different features of a driver and presents different difficulties. This chapter covers the internals of scull0 to scull3; the more advanced devices are covered in Chapter 6. scullpipe is described in the section Section 3.4 and the others are described in Section 6.6

查尔设备被访问通过 文件系统中的名称。这些名称称为特殊文件或设备文件或简称为文件系统树的节点；它们通常位于/dev 目录。字符驱动程序的特殊文件由ls -l输出的第一列中的“c”标识。块设备也出现在/dev中，但它们由“b”标识。本章的重点是字符设备，但以下大部分信息也适用于块设备。

Char devices are accessed through names in the filesystem. Those names are called special files or device files or simply nodes of the filesystem tree; they are conventionally located in the /dev directory. Special files for char drivers are identified by a "c" in the first column of the output of ls -l. Block devices appear in /dev as well, but they are identified by a "b." The focus of this chapter is on char devices, but much of the following information applies to block devices as well.

如果发出ls -l命令，您将在上次修改日期之前的设备文件条目中看到两个数字（以逗号分隔），其中通常显示文件长度。这些数字是特定设备的主设备号和次设备号。以下列表显示了典型系统上出现的一些设备。它们的大数是 1、4、7 和 10，小数是 1、3、5、64、65 和 129。

If you issue the ls -l command, you'll see two numbers (separated by a comma) in the device file entries before the date of the last modification, where the file length normally appears. These numbers are the major and minor device number for the particular device. The following listing shows a few devices as they appear on a typical system. Their major numbers are 1, 4, 7, and 10, while the minors are 1, 3, 5, 64, 65, and 129.

crw-rw-rw- 1 根 根 1, 3 Apr 11 2002 null
 crw----- 1 根 根 10, 2002 年 4 月 11 日 1 日 psaux
 crw----- 1 root root 4, 1 Oct 28 03:04 tty1
 crw-rw-rw- 1 root tty 4, 64 2002 年 4 月 11 日 ttys0
 crw-rw---- 1 root uucp 4, 65 2002 年 4 月 11 日 ttyS1
 crw--w---- 1 vcsa tty 7, 2002 年 4 月 11 日 1 日 vcs1
 crw--w---- 1 vcsa tty 7, 129 2002 年 4 月 11 日 vcsa1
 crw-rw-rw- 1 根 根 1, 5 Apr 11 2002 零

 crw-rw-rw-    1 root     root       1,   3 Apr 11  2002 null
 crw-------    1 root     root      10,   1 Apr 11  2002 psaux
 crw-------    1 root     root       4,   1 Oct 28 03:04 tty1
 crw-rw-rw-    1 root     tty        4,  64 Apr 11  2002 ttys0
 crw-rw----    1 root     uucp       4,  65 Apr 11  2002 ttyS1
 crw--w----    1 vcsa     tty        7,   1 Apr 11  2002 vcs1
 crw--w----    1 vcsa     tty        7, 129 Apr 11  2002 vcsa1
 crw-rw-rw-    1 root     root       1,   5 Apr 11  2002 zero

传统上，主编号标识与设备关联的驱动程序。例如，/dev/null和/dev/zero均由驱动程序 1 管理，而虚拟控制台和串行终端由驱动程序 4 管理；同样，vcs1 和vcsa1设备均由驱动程序 7 管理。现代 Linux 内核允许多个驱动程序共享主设备号，但您将看到的大多数设备仍然按照一主设备一驱动程序原则进行组织。

Traditionally, the major number identifies the driver associated with the device. For example, /dev/null and /dev/zero are both managed by driver 1, whereas virtual consoles and serial terminals are managed by driver 4; similarly, both vcs1 and vcsa1 devices are managed by driver 7. Modern Linux kernels allow multiple drivers to share major numbers, but most devices that you will see are still organized on the one-major-one-driver principle.

内核使用次设备号来准确确定所引用的设备。根据驱动程序的编写方式（如下所示），您可以从内核获取指向设备的直接指针，也可以自己使用次要编号作为本地设备数组的索引。不管怎样，内核本身对次要数字几乎一无所知，除了它们引用驱动程序实现的设备这一事实之外。

The minor number is used by the kernel to determine exactly which device is being referred to. Depending on how your driver is written (as we will see below), you can either get a direct pointer to your device from the kernel, or you can use the minor number yourself as an index into a local array of devices. Either way, the kernel itself knows almost nothing about minor numbers beyond the fact that they refer to devices implemented by your driver.

主要（dev_t dev）；
次要（dev_t dev）；

MAJOR(dev_t dev);
MINOR(dev_t dev);

MKDEV(int 大调, int 小调);

MKDEV(int major, int minor);

int register_chrdev_region(dev_t 首先，无符号整数计数，
                           字符*名称）；

int register_chrdev_region(dev_t first, unsigned int count, 
                           char *name);

int alloc_chrdev_region(dev_t *dev, 无符号整数firstminor,
                        无符号整数计数，字符*名称）；

int alloc_chrdev_region(dev_t *dev, unsigned int firstminor, 
                        unsigned int count, char *name);

void unregister_chrdev_region(dev_t 首先，无符号整数计数);

void unregister_chrdev_region(dev_t first, unsigned int count);

字符设备：
 1内存
 2 人
 3 打字机
 4 个终端
 6 LP
 7 个VC
 10 杂项
 13输入
 14声
 21 SG
180个USB

块设备：
 2 FD
 8 标准差
 11 高级
 65标清
 66标清

Character devices:
 1 mem
 2 pty
 3 ttyp
 4 ttyS
 6 lp
 7 vcs
 10 misc
 13 input
 14 sound
 21 sg
180 usb

Block devices:
 2 fd
 8 sd
 11 sr
 65 sd
 66 sd

#!/bin/sh
模块=“双桨”
设备=“双桨”
模式=“664”

# 使用我们得到的所有参数调用 insmod
# 并使用路径名，因为较新的 modutils 不会在 . 默认情况下
/sbin/insmod ./$module.ko $* || 1号出口

# 删除旧节点
rm -f /dev/${设备}[0-3]

主要=$(awk "\\$2= =\"$module\" {print \\$1}" /proc/devices)

mknod /dev/${device}0 c $major 0
mknod /dev/${device}1 c $major 1
mknod /dev/${device}2 c $major 2
mknod /dev/${device}3 c $major 3

# 给予适当的组/权限，并更改组。
# 并非所有发行版都有员工，有些发行版有“轮子”。
组=“工作人员”
grep -q '^员工：' /etc/group || 组=“轮子”

chgrp $group /dev/${设备}[0-3]
chmod $mode /dev/${设备}[0-3]

#!/bin/sh
module="scull"
device="scull"
mode="664"

# invoke insmod with all arguments we got
# and use a pathname, as newer modutils don't look in . by default
/sbin/insmod ./$module.ko $* || exit 1

# remove stale nodes
rm -f /dev/${device}[0-3]

major=$(awk "\\$2=  =\"$module\" {print \\$1}" /proc/devices)

mknod /dev/${device}0 c $major 0
mknod /dev/${device}1 c $major 1
mknod /dev/${device}2 c $major 2
mknod /dev/${device}3 c $major 3

# give appropriate group/permissions, and change the group.
# Not all distributions have staff, some have "wheel" instead.
group="staff"
grep -q '^staff:' /etc/group || group="wheel"

chgrp $group /dev/${device}[0-3]
chmod $mode  /dev/${device}[0-3]

如果（双桨大调）{
    dev = MKDEV(scull_major, scull_minor);
    结果 = register_chrdev_region(dev, scull_nr_devs, "scull");
} 别的 {
    结果 = alloc_chrdev_region(&dev, scull_minor, scull_nr_devs,
            “橹”）;
    scull_major = 主要(dev);
}
如果（结果 < 0）{
    printk(KERN_WARNING "scull: 无法获取主要 %d\n", scull_major);
    返回结果；
}

if (scull_major) {
    dev = MKDEV(scull_major, scull_minor);
    result = register_chrdev_region(dev, scull_nr_devs, "scull");
} else {
    result = alloc_chrdev_region(&dev, scull_minor, scull_nr_devs,
            "scull");
    scull_major = MAJOR(dev);
}
if (result < 0) {
    printk(KERN_WARNING "scull: can't get major %d\n", scull_major);
    return result;
}

可以想象，设备号注册 这只是驱动程序代码必须执行的众多任务中的第一个。我们很快就会看到其他重要的驱动程序组件，但首先需要另一个题外话。大多数基本驱动程序操作都涉及三个重要的内核数据结构，称为file_operations、file和inode。需要对这些结构有基本的熟悉才能完成许多有趣的事情，因此我们现在将快速浏览一下它们中的每一个，然后再详细了解如何实现基本驱动程序操作。

As you can imagine, device number registration is just the first of many tasks that driver code must carry out. We will soon look at other important driver components, but one other digression is needed first. Most of the fundamental driver operations involve three important kernel data structures, called file_operations, file, and inode. A basic familiarity with these structures is required to be able to do much of anything interesting, so we will now take a quick look at each of them before getting into the details of how to implement the fundamental driver operations.

结构文件操作 scull_fops = {
    .owner = THIS_MODULE，
    .llseek = scull_llseek,
    .read = scull_read,
    .write = scull_write，
    .ioctl = scull_ioctl,
    .open = scull_open,
    .release = scull_release,
};

struct file_operations scull_fops = {
    .owner =    THIS_MODULE,
    .llseek =   scull_llseek,
    .read =     scull_read,
    .write =    scull_write,
    .ioctl =    scull_ioctl,
    .open =     scull_open,
    .release =  scull_release,
};

无符号 int imminor(struct inode *inode);
无符号 int imajor(struct inode *inode);

unsigned int iminor(struct inode *inode);
unsigned int imajor(struct inode *inode);

正如我们提到的，内核使用 struct cdev内部表示字符设备的类型结构。在内核调用设备的操作之前，您必须分配并注册这些结构中的一个或多个。^{[ 6 ]}为此，您的代码应包含<linux/cdev.h>，其中定义了结构及其关联的辅助函数。

As we mentioned, the kernel uses structures of type struct cdev to represent char devices internally. Before the kernel invokes your device's operations, you must allocate and register one or more of these structures.^[6] To do so, your code should include <linux/cdev.h>, where the structure and its associated helper functions are defined.

有两种方法可以分配和初始化这些结构之一。如果您希望cdev在运行时获得独立的结构，您可以使用以下代码来实现：

There are two ways of allocating and initializing one of these structures. If you wish to obtain a standalone cdev structure at runtime, you may do so with code such as:

结构 cdev *my_cdev = cdev_alloc( );
my_cdev->ops = &my_fops;

struct cdev *my_cdev = cdev_alloc(  );
my_cdev->ops = &my_fops;

然而，您可能希望将该cdev结构嵌入到您自己的特定于设备的结构中；这就是 双桨的作用。在这种情况下，您应该初始化已经分配的结构：

Chances are, however, that you will want to embed the cdev structure within a device-specific structure of your own; that is what scull does. In that case, you should initialize the structure that you have already allocated with:

void cdev_init(struct cdev *cdev, struct file_operations *fops);

void cdev_init(struct cdev *cdev, struct file_operations *fops);

struct cdev无论哪种方式，您都需要初始化另一个字段。与file_operations结构一样，struct cdev有一个owner 应设置为 的字段THIS_MODULE。

Either way, there is one other struct cdev field that you need to initialize. Like the file_operations structure, struct cdev has an owner field that should be set to THIS_MODULE.

一旦cdev 结构设置完毕后，最后一步是通过调用以下命令告诉内核：

Once the cdev structure is set up, the final step is to tell the kernel about it with a call to:

int cdev_add(struct cdev *dev, dev_t num, unsigned int count);

int cdev_add(struct cdev *dev, dev_t num, unsigned int count);

这里，dev是cdev结构体，num是该设备响应的第一个设备号，count是应该与该设备关联的设备号的数量。通常count是一个，但在某些情况下，有多个设备编号对应于一个特定设备是有意义的。例如，考虑一下 SCSI 磁带驱动程序，它允许用户空间通过为每个物理设备分配多个次要编号来选择操作模式（例如密度）。

Here, dev is the cdev structure, num is the first device number to which this device responds, and count is the number of device numbers that should be associated with the device. Often count is one, but there are situations where it makes sense to have more than one device number correspond to a specific device. Consider, for example, the SCSI tape driver, which allows user space to select operating modes (such as density) by assigning multiple minor numbers to each physical device.

使用cdev_add时需要记住一些重要的事情 。首先是这个调用可能会失败。如果它返回负错误代码，则表明您的设备尚未添加到系统中。然而，它几乎总是成功，这就引出了另一点：一旦 cdev_add返回，您的设备就处于“活动”状态，并且内核可以调用其操作。在驱动程序完全准备好处理设备上的操作之前，不应调用cdev_add 。

There are a couple of important things to keep in mind when using cdev_add. The first is that this call can fail. If it returns a negative error code, your device has not been added to the system. It almost always succeeds, however, and that brings up the other point: as soon as cdev_add returns, your device is "live" and its operations can be called by the kernel. You should not call cdev_add until your driver is completely ready to handle operations on the device.

要从系统中删除字符设备，请调用：

To remove a char device from the system, call:

无效cdev_del（结构cdev * dev）；

void cdev_del(struct cdev *dev);

显然，您不应cdev在将结构传递给cdev_del后访问该结构。

Clearly, you should not access the cdev structure after passing it to cdev_del.

结构 scull_dev {
    结构 scull_qset *数据；/* 指向第一个量子集的指针 */
    整数量子；/* 当前量子大小 */
    int qset；/* 当前数组大小 */
    无符号长尺寸；/* 这里存储的数据量 */
    无符号整型访问密钥；/* 由 sculluid 和 scullpriv 使用 */
    结构信号量 sem；/* 互斥信号量 */
    结构体cdev cdev；/* Char设备结构*/
};

struct scull_dev {
    struct scull_qset *data;  /* Pointer to first quantum set */
    int quantum;              /* the current quantum size */
    int qset;                 /* the current array size */
    unsigned long size;       /* amount of data stored here */
    unsigned int access_key;  /* used by sculluid and scullpriv */
    struct semaphore sem;     /* mutual exclusion semaphore     */
    struct cdev cdev;     /* Char device structure      */
};

静态无效 scull_setup_cdev(结构 scull_dev *dev, int 索引)
{
    int err, devno = MKDEV(scull_major, scull_minor + 索引);
    
    cdev_init(&dev->cdev, &scull_fops);
    dev->cdev.owner = THIS_MODULE;
    dev->cdev.ops = &scull_fops;
    err = cdev_add(&dev->cdev, devno, 1);
    /* 如果需要则优雅地失败 */
    如果（错误）
    printk(KERN_NOTICE "添加 scull%d 时出错 %d", err, index);
}

static void scull_setup_cdev(struct scull_dev *dev, int index)
{
    int err, devno = MKDEV(scull_major, scull_minor + index);
    
    cdev_init(&dev->cdev, &scull_fops);
    dev->cdev.owner = THIS_MODULE;
    dev->cdev.ops = &scull_fops;
    err = cdev_add (&dev->cdev, devno, 1);
    /* Fail gracefully if need be */
    if (err)
    printk(KERN_NOTICE "Error %d adding scull%d", err, index);
}

int register_chrdev(无符号 int 主要, const char *名称,
                    结构文件操作 *fops);

int register_chrdev(unsigned int major, const char *name,
                    struct file_operations *fops);

int unregister_chrdev(unsigned int Major, const char *name);

int unregister_chrdev(unsigned int major, const char *name);

现在我们已经快速浏览了这些字段，我们开始在真正的 scull函数中使用它们。

Now that we've taken a quick look at the fields, we start using them in real scull functions.

int (*open)(struct inode *inode, struct file *filp);

int (*open)(struct inode *inode, struct file *filp);

容器_of（指针，容器类型，容器字段）；

container_of(pointer, container_type, container_field);

结构 scull_dev *dev; /* 设备信息 */

dev = container_of(inode->i_cdev, struct scull_dev, cdev);
filp->private_data = dev; /* 对于其他方法 */

struct scull_dev *dev; /* device information */

dev = container_of(inode->i_cdev, struct scull_dev, cdev);
filp->private_data = dev; /* for other methods */

int scull_open(结构 inode *inode, 结构文件 *filp)
{
    结构 scull_dev *dev; /* 设备信息 */

    dev = container_of(inode->i_cdev, struct scull_dev, cdev);
    filp->private_data = dev; /* 对于其他方法 */

    /* 如果 open 是只写的，现在将设备的长度修剪为 0 */
    if ( (filp->f_flags & O_ACCMODE) == O_WRONLY) {
        scull_trim（开发）；/* 忽略错误 */
    }
    返回0；/* 成功 */
}

int scull_open(struct inode *inode, struct file *filp)
{
    struct scull_dev *dev; /* device information */

    dev = container_of(inode->i_cdev, struct scull_dev, cdev);
    filp->private_data = dev; /* for other methods */

    /* now trim to 0 the length of the device if open was write-only */
    if ( (filp->f_flags & O_ACCMODE) =  = O_WRONLY) {
        scull_trim(dev); /* ignore errors */
    }
    return 0;          /* success */
}

int scull_release(结构 inode *inode, 结构文件 *filp)
{
    返回0；
}

int scull_release(struct inode *inode, struct file *filp)
{
    return 0;
}

在介绍阅读和之前 写操作之前，我们最好看看 scull 是如何以及为何进行内存分配的。需要“如何”来彻底理解代码，“为什么”则展示了驱动程序编写者需要做出的选择，尽管scull绝对不是典型的设备。

Before introducing the read and write operations, we'd better look at how and why scull performs memory allocation. "How" is needed to thoroughly understand the code, and "why" demonstrates the kind of choices a driver writer needs to make, although scull is definitely not typical as a device.

本节仅讨论scull中的内存分配策略 ，并不展示编写真正的驱动程序所需的硬件管理技能。这些技能将在第 9 章和第 10 章中介绍。因此，如果您对了解面向内存的 scull驱动程序的内部工作原理不感兴趣，则可以跳过本节。

This section deals only with the memory allocation policy in scull and doesn't show the hardware management skills you need to write real drivers. These skills are introduced in Chapter 9 and Chapter 10. Therefore, you can skip this section if you're not interested in understanding the inner workings of the memory-oriented scull driver.

scull使用的内存区域（也称为 设备）的长度是可变的。你写得越多，它就越长；修剪是通过用较短的文件覆盖设备来执行的。

The region of memory used by scull, also called a device, is variable in length. The more you write, the more it grows; trimming is performed by overwriting the device with a shorter file.

scull驱动程序引入了两个用于管理 Linux 内核内存的核心函数。这些函数定义在<linux/slab.h>中，它们是：

The scull driver introduces two core functions used to manage memory in the Linux kernel. These functions, defined in <linux/slab.h>, are:

void *kmalloc(size_t 大小，int 标志);
无效kfree（无效* ptr）；

void *kmalloc(size_t size, int flags);
void kfree(void *ptr);

对kmalloc 的调用尝试分配size内存字节；返回值是指向该内存的指针，或者NULL如果分配失败。该flags参数用于描述内存应该如何分配；我们将在第 8 章中详细研究这些标志。目前，我们总是使用GFP_KERNEL. 分配的内存应使用kfree释放。您永远不应该将任何 不是从kmalloc获得的东西传递给kfree。但是，将指针传递给 kfree是合法的。NULL

A call to kmalloc attempts to allocate size bytes of memory; the return value is a pointer to that memory or NULL if the allocation fails. The flags argument is used to describe how the memory should be allocated; we examine those flags in detail in Chapter 8. For now, we always use GFP_KERNEL. Allocated memory should be freed with kfree. You should never pass anything to kfree that was not obtained from kmalloc. It is, however, legal to pass a NULL pointer to kfree.

kmalloc不是分配大面积内存的最有效方法（请参阅第 8 章），因此为scull选择的实现 并不是一个特别聪明的实现。智能实现的源代码将更难以阅读，本节的目的是展示 读取和写入，而不是内存管理。这就是为什么代码只使用kmalloc和kfree而没有诉诸整个页面的分配，尽管这种方法会更有效。

kmalloc is not the most efficient way to allocate large areas of memory (see Chapter 8), so the implementation chosen for scull is not a particularly smart one. The source code for a smart implementation would be more difficult to read, and the aim of this section is to show read and write, not memory management. That's why the code just uses kmalloc and kfree without resorting to allocation of whole pages, although that approach would be more efficient.

另一方面，出于哲学原因和实际原因，我们不想限制“设备”区域的大小。从哲学上讲，对所管理的数据项施加任意限制总是一个坏主意。实际上，scull可用于暂时耗尽系统内存，以便在内存不足的情况下运行测试。运行此类测试可能会帮助您了解系统的内部结构。您可以使用命令cp /dev/zero /dev/scull0来使用scull占用所有实际 RAM ，并且可以使用dd实用程序来选择将多少数据复制到 scull设备。

On the flip side, we didn't want to limit the size of the "device" area, for both a philosophical reason and a practical one. Philosophically, it's always a bad idea to put arbitrary limits on data items being managed. Practically, scull can be used to temporarily eat up your system's memory in order to run tests under low-memory conditions. Running such tests might help you understand the system's internals. You can use the command cp /dev/zero /dev/scull0 to eat all the real RAM with scull, and you can use the dd utility to choose how much data is copied to the scull device.

在scull中，每个设备都是一个链表 指针，每个指针都指向一个scull_dev结构。默认情况下，每个此类结构可以通过中间指针数组引用最多 400 万字节。发布的源代码使用了一个由 1000 个指针组成的数组，指向 4000 字节的区域。我们将每个存储区域称为一个量子，将数组（或其长度）称为一个量子集 。scull设备 及其内存区域如图 3-1所示。

In scull, each device is a linked list of pointers, each of which points to a scull_dev structure. Each such structure can refer, by default, to at most four million bytes, through an array of intermediate pointers. The released source uses an array of 1000 pointers to areas of 4000 bytes. We call each memory area a quantum and the array (or its length) a quantum set . A scull device and its memory areas are shown in Figure 3-1.

图 3-1。scull 设备的布局

Figure 3-1. The layout of a scull device

选择的数字使得在scull 中写入单个字节会消耗 8000 或 12,000 千字节的内存：量子为 4000，量子集为 4000 或 8000（根据指针在目标上以 32 位还是 64 位表示）平台）。相反，如果写入大量数据，链表的开销也不会太糟糕。每四兆字节的数据只有一个列表元素，设备的最大大小受到计算机内存大小的限制。

The chosen numbers are such that writing a single byte in scull consumes 8000 or 12,000 thousand bytes of memory: 4000 for the quantum and 4000 or 8000 for the quantum set (according to whether a pointer is represented in 32 bits or 64 bits on the target platform). If, instead, you write a huge amount of data, the overhead of the linked list is not too bad. There is only one list element for every four megabytes of data, and the maximum size of the device is limited by the computer's memory size.

为量子和量子集选择适当的值是一个策略问题，而不是机制问题，并且最佳大小取决于设备的使用方式。因此，scull驱动程序不应强制使用量子和量子集大小的任何特定值。在scull中，用户可以通过多种方式更改负责的值：通过在编译时更改宏和 scull.hSCULL_QUANTUM，SCULL_QSET通过在 模块加载时 设置整数值，或者通过使用ioctl更改当前值和默认值在运行时。scull_quantumscull_qset

Choosing the appropriate values for the quantum and the quantum set is a question of policy, rather than mechanism, and the optimal sizes depend on how the device is used. Thus, the scull driver should not force the use of any particular values for the quantum and quantum set sizes. In scull, the user can change the values in charge in several ways: by changing the macros SCULL_QUANTUM and SCULL_QSET in scull.h at compile time, by setting the integer values scull_quantum and scull_qset at module load time, or by changing both the current and default values using ioctl at runtime.

使用宏和整数值来允许编译时和加载时配置让人想起如何选择主编号。我们将这种技术用于驱动程序中任意值或与策略相关的值。

Using a macro and an integer value to allow both compile-time and load-time configuration is reminiscent of how the major number is selected. We use this technique for whatever value in the driver is arbitrary or related to policy.

剩下的唯一问题是如何选择默认数字。在这种特殊情况下，问题是在半填充量子和量子集导致的内存浪费与量子和集较小时发生的分配、释放和指针链接的开销之间找到最佳平衡。此外，还应考虑kmalloc的内部设计。（不过，我们现在不追究这个问题；kmalloc的内部结构将在第 8 章中探讨。）默认数字的选择来自于这样的假设：大量数据可能会写入 scull在测试时，尽管正常使用该设备很可能只会传输几千字节的数据。

The only question left is how the default numbers have been chosen. In this particular case, the problem is finding the best balance between the waste of memory resulting from half-filled quanta and quantum sets and the overhead of allocation, deallocation, and pointer chaining that occurs if quanta and sets are small. Additionally, the internal design of kmalloc should be taken into account. (We won't pursue the point now, though; the innards of kmalloc are explored in Chapter 8.) The choice of default numbers comes from the assumption that massive amounts of data are likely to be written to scull while testing it, although normal use of the device will most likely transfer just a few kilobytes of data.

我们已经看到了scull_dev代表我们设备内部的结构。该结构quantum和qset字段分别保存设备的量子和量子集大小。然而实际数据是由不同的结构跟踪，我们称之为 struct scull_qset ：

We have already seen the scull_dev structure that represents our device internally. That structure's quantum and qset fields hold the device's quantum and quantum set sizes, respectively. The actual data, however, is tracked by a different structure, which we call struct scull_qset :

结构 scull_qset {
    无效**数据；
    结构 scull_qset *下一个;
};

struct scull_qset {
    void **data;
    struct scull_qset *next;
};

下一个代码片段在实践中展示了如何使用struct scull_dev和来保存数据。struct scull_qset函数 scull_trim负责释放整个数据区域，并在文件打开写入时由scull_open调用。它只是遍历列表并释放它找到的任何量子和量子集。

The next code fragment shows in practice how struct scull_dev and struct scull_qset are used to hold data. The function scull_trim is in charge of freeing the whole data area and is invoked by scull_open when the file is opened for writing. It simply walks through the list and frees any quantum and quantum set it finds.

int scull_trim(结构 scull_dev *dev)
{
    结构 scull_qset *next, *dptr;
    int qset = dev->qset; /* “dev” 不为空 */
    整数我；

    for (dptr = dev->data; dptr; dptr = next) { /* 所有列表项 */
        if (dptr->数据) {
            for (i = 0; i < qset; i++)
                kfree(dptr->data[i]);
            kfree(dptr->数据);
            dptr->数据=NULL；
        }
        下一个 = dptr->下一个；
        kfree(dptr);
    }
    开发->大小=0；
    dev->quantum = scull_quantum;
    dev->qset = scull_qset;
    dev->数据=NULL；
    返回0；
}

int scull_trim(struct scull_dev *dev)
{
    struct scull_qset *next, *dptr;
    int qset = dev->qset;   /* "dev" is not-null */
    int i;

    for (dptr = dev->data; dptr; dptr = next) { /* all the list items */
        if (dptr->data) {
            for (i = 0; i < qset; i++)
                kfree(dptr->data[i]);
            kfree(dptr->data);
            dptr->data = NULL;
        }
        next = dptr->next;
        kfree(dptr);
    }
    dev->size = 0;
    dev->quantum = scull_quantum;
    dev->qset = scull_qset;
    dev->data = NULL;
    return 0;
}

scull_trim也用于 模块清理函数将scull使用的内存返回给系统。

scull_trim is also used in the module cleanup function to return memory used by scull to the system.

读写 方法都有_ _ 执行类似的任务，即将数据从应用程序代码复制到应用程序代码。因此，它们的原型非常相似，值得同时介绍：

The read and write methods both perform a similar task, that is, copying data from and to application code. Therefore, their prototypes are pretty similar, and it's worth introducing them at the same time:

ssize_t read(struct file *filp, char _ _user *buff,
    size_t 计数，loff_t *offp);
ssize_t write(struct file *filp, const char _ _user *buff,
    size_t 计数，loff_t *offp);

ssize_t read(struct file *filp, char _ _user *buff,
    size_t count, loff_t *offp);
ssize_t write(struct file *filp, const char _ _user *buff,
    size_t count, loff_t *offp);

对于这两种方法，filp 是文件指针，count是请求的数据传输的大小。该buff参数指向保存要写入的数据的用户缓冲区或应放置新读取的数据的空缓冲区。最后，offp是一个指向“长偏移类型”对象的指针，该对象指示用户正在访问的文件位置。返回值是一个“有符号大小类型”；其用途稍后讨论。

For both methods, filp is the file pointer and count is the size of the requested data transfer. The buff argument points to the user buffer holding the data to be written or the empty buffer where the newly read data should be placed. Finally, offp is a pointer to a "long offset type" object that indicates the file position the user is accessing. The return value is a "signed size type"; its use is discussed later.

让我们重复一遍，读写方法的buff参数 是用户空间指针。因此，它不能被内核代码直接取消引用。造成此限制的原因有以下几个：

Let us repeat that the buff argument to the read and write methods is a user-space pointer. Therefore, it cannot be directly dereferenced by kernel code. There are a few reasons for this restriction:

显然，您的驱动程序必须能够访问用户空间缓冲区才能完成其工作。然而，为了安全起见，这种访问必须始终由内核提供的特殊函数执行。我们在这里介绍其中一些函数（在<asm/uaccess.h>中定义 ），其余的在第 6.1.4 节中介绍；他们使用一些特殊的、依赖于体系结构的魔法来确保内核和用户空间之间的数据传输以安全和正确的方式进行。

Obviously, your driver must be able to access the user-space buffer in order to get its job done. This access must always be performed by special, kernel-supplied functions, however, in order to be safe. We introduce some of those functions (which are defined in <asm/uaccess.h>) here, and the rest in the Section 6.1.4; they use some special, architecture-dependent magic to ensure that data transfers between kernel and user space happen in a safe and correct way.

scull中 的读写代码需要将一整段数据复制到用户地址空间或从用户地址空间复制出来。此功能由以下内核函数 提供，它们复制任意字节数组并位于大多数读写实现的核心：

The code for read and write in scull needs to copy a whole segment of data to or from the user address space. This capability is offered by the following kernel functions, which copy an arbitrary array of bytes and sit at the heart of most read and write implementations:

无符号长 copy_to_user(void __user *to,
                           常量无效*来自，
                           无符号长计数）；
无符号长 copy_from_user(void *to,
                             const void _ _user *来自，
                             无符号长计数）；

unsigned long copy_to_user(void _ _user *to, 
                           const void *from, 
                           unsigned long count);
unsigned long copy_from_user(void *to, 
                             const void _ _user *from, 
                             unsigned long count);

尽管这些函数的行为类似于普通的memcpy函数，但从内核代码访问用户空间时必须格外小心。正在寻址的用户页面当前可能不存在于内存中，并且虚拟内存子系统可以在页面传输到位时使进程进入睡眠状态。例如，当必须从交换空间检索页面时，就会发生这种情况。驱动程序编写者的最终结果是任何访问用户空间的函数都必须是可重入的，必须能够与其他驱动程序函数同时执行，特别是必须处于可以合法休眠的位置。我们将在第 5 章中回到这个主题。

Although these functions behave like normal memcpy functions, a little extra care must be used when accessing user space from kernel code. The user pages being addressed might not be currently present in memory, and the virtual memory subsystem can put the process to sleep while the page is being transferred into place. This happens, for example, when the page must be retrieved from swap space. The net result for the driver writer is that any function that accesses user space must be reentrant, must be able to execute concurrently with other driver functions, and, in particular, must be in a position where it can legally sleep. We return to this subject in Chapter 5.

这两个函数的作用不仅限于将数据复制到用户空间或从用户空间复制数据：它们还检查用户空间指针是否有效。如果指针无效，则不执行复制；另一方面，如果在复制过程中遇到无效地址，则仅复制部分数据。在这两种情况下，返回值都是仍要复制的内存量。scull代码会查找此错误返回， -EFAULT如果不是则返回给用户0。

The role of the two functions is not limited to copying data to and from user-space: they also check whether the user space pointer is valid. If the pointer is invalid, no copy is performed; if an invalid address is encountered during the copy, on the other hand, only part of the data is copied. In both cases, the return value is the amount of memory still to be copied. The scull code looks for this error return, and returns -EFAULT to the user if it's not 0.

用户空间访问和无效用户空间指针的主题有些高级，将在第 6 章中讨论。然而，值得注意的是，如果您不需要检查用户空间指针，您可以调用__copy_to_user和__copy_from_user来代替。例如，如果您知道您已经检查了参数，那么这很有用。但要小心；事实上，如果您不检查传递给这些函数的用户空间指针，那么您可能会造成内核崩溃和/或安全漏洞。

The topic of user-space access and invalid user space pointers is somewhat advanced and is discussed in Chapter 6. However, it's worth noting that if you don't need to check the user-space pointer you can invoke _ _copy_to_user and _ _copy_from_user instead. This is useful, for example, if you know you already checked the argument. Be careful, however; if, in fact, you do not check a user-space pointer that you pass to these functions, then you can create kernel crashes and/or security holes.

就实际的设备方法而言， 读取方法的任务是将数据从设备复制到用户空间（使用 copy_to_user），而写入方法必须将数据从用户空间复制到设备（使用copy_from_user）。每个 读取或写入系统调用都请求传输特定数量的字节，但驱动程序可以自由地传输较少的数据 - 读取和写入的确切规则略有不同，将在本章后面进行描述。

As far as the actual device methods are concerned, the task of the read method is to copy data from the device to user space (using copy_to_user), while the write method must copy data from user space to the device (using copy_from_user). Each read or write system call requests transfer of a specific number of bytes, but the driver is free to transfer less data—the exact rules are slightly different for reading and writing and are described later in this chapter.

无论方法传输多少数据量，它们通常应该*offp在成功完成系统调用后更新文件位置以表示当前文件位置。然后，内核file在适当的时候将文件位置更改传播回结构中。然而，pread和 pwrite系统调用具有不同的语义；它们从给定的文件偏移量开始操作，并且不会更改任何其他系统调用所看到的文件位置。这些调用传递一个指向用户提供的位置的指针，并丢弃驱动程序所做的更改。

Whatever the amount of data the methods transfer, they should generally update the file position at *offp to represent the current file position after successful completion of the system call. The kernel then propagates the file position change back into the file structure when appropriate. The pread and pwrite system calls have different semantics, however; they operate from a given file offset and do not change the file position as seen by any other system calls. These calls pass in a pointer to the user-supplied position, and discard the changes that your driver makes.

图 3-2展示了典型的 读取实现如何使用其参数。

Figure 3-2 represents how a typical read implementation uses its arguments.

图 3-2。需要阅读的论据

Figure 3-2. The arguments to read

如果发生错误，读取 和写入方法都会返回负值。相反，大于或等于 0 的返回值告诉调用程序已成功传输了多少字节。如果某些数据传输正确，然后发生错误，则返回值必须是成功传输的字节数，并且直到下次调用该函数时才会报告错误。当然，实现此约定需要您的驱动程序记住已发生错误，以便将来可以返回错误状态。

Both the read and write methods return a negative value if an error occurs. A return value greater than or equal to 0, instead, tells the calling program how many bytes have been successfully transferred. If some data is transferred correctly and then an error happens, the return value must be the count of bytes successfully transferred, and the error does not get reported until the next time the function is called. Implementing this convention requires, of course, that your driver remember that the error has occurred so that it can return the error status in the future.

尽管内核函数返回一个负数来表示错误，并且该数字的值指示发生的错误类型（如第2 章所述），但在用户空间中运行的程序始终将其视为 -1错误返回值。他们需要访问该 errno变量以了解发生了什么。用户空间行为由 POSIX 标准规定，但该标准并未对内核内部运行方式提出要求。

Although kernel functions return a negative number to signal an error, and the value of the number indicates the kind of error that occurred (as introduced in Chapter 2), programs that run in user space always see -1 as the error return value. They need to access the errno variable to find out what happened. The user-space behavior is dictated by the POSIX standard, but that standard does not make requirements on how the kernel operates internally.

ssize_t scull_read(struct file *filp, char _ _user *buf, size_t count,
                loff_t *f_pos)
{
    struct scull_dev *dev = filp->private_data;
    结构 scull_qset *dptr; /* 第一个列表项 */
    int 量子，qset；
    int 项目大小；/* 列表项有多少字节 */
    int item，s_pos，q_pos，其余；
    ssize_t retval = 0;

    if (down_interruptible(&dev->sem))
        返回-ERESTARTSYS；
    量子 = dev->量子；
    qset = dev->qset;
    项目大小=量子*qset；
        
    if (*f_pos >= dev->size)
       转到出去；
    if (*f_pos + 计数 > dev->size)
       计数 = dev->大小 - *f_pos;

    /* 查找列表项、qset 索引和量程中的偏移量 */
    item = (long)*f_pos / itemsize;
    休息 = (长)*f_pos % 项目大小;
    s_pos = 休息 / 量子; q_pos = 剩余% 量子；

    /* 跟随列表直到正确的位置（在别处定义） */
    dptr = scull_follow(dev, 项目);

    if (dptr == NULL || !dptr->data || !dptr->data[s_pos])
        转到出去；/* 不填坑 */

    /* 只读到该量程的末尾 */
    if (计数 > 量子 - q_pos)
        计数=量子-q_pos；

    if (copy_to_user(buf, dptr->data[s_pos] + q_pos, count)) {
        retval = -EFAULT；
        转到出去；
    }
    *f_pos += 计数；
    retval = 计数；

  出去：
    向上（&dev->sem）；
    返回retval；
}

ssize_t scull_read(struct file *filp, char _ _user *buf, size_t count,
                loff_t *f_pos)
{
    struct scull_dev *dev = filp->private_data; 
    struct scull_qset *dptr;    /* the first listitem */
    int quantum, qset;
    int itemsize; /* how many bytes in the listitem */
    int item, s_pos, q_pos, rest;
    ssize_t retval = 0;

    if (down_interruptible(&dev->sem))
        return -ERESTARTSYS;
    quantum = dev->quantum;
    qset = dev->qset;
    itemsize = quantum*qset;
        
    if (*f_pos >= dev->size)
       goto out;
    if (*f_pos + count > dev->size)
       count = dev->size - *f_pos;

    /* find listitem, qset index, and offset in the quantum */
    item = (long)*f_pos / itemsize;
    rest = (long)*f_pos % itemsize;
    s_pos = rest / quantum; q_pos = rest % quantum;

    /* follow the list up to the right position (defined elsewhere) */
    dptr = scull_follow(dev, item);

    if (dptr =  = NULL || !dptr->data || ! dptr->data[s_pos])
        goto out; /* don't fill holes */

    /* read only up to the end of this quantum */
    if (count > quantum - q_pos)
        count = quantum - q_pos;

    if (copy_to_user(buf, dptr->data[s_pos] + q_pos, count)) {
        retval = -EFAULT;
        goto out;
    }
    *f_pos += count;
    retval = count;

  out:
    up(&dev->sem);
    return retval;
}

ssize_t scull_write(struct file *filp, const char _ _user *buf, size_t count,
                loff_t *f_pos)
{
    struct scull_dev *dev = filp->private_data;
    结构 scull_qset *dptr;
    int 量子= dev->量子，qset = dev->qset；
    int itemsize = 量子 * qset;
    int item，s_pos，q_pos，其余；
    ssize_t retval = -ENOMEM；/* “goto out” 语句中使用的值 */

    if (down_interruptible(&dev->sem))
        返回-ERESTARTSYS；

    /* 在量程中查找 listitem、qset 索引和偏移量 */
    item = (long)*f_pos / itemsize;
    休息 = (长)*f_pos % 项目大小;
    s_pos = 休息 / 量子; q_pos = 剩余% 量子；

    /* 跟随列表直到正确的位置 */
    dptr = scull_follow(dev, 项目);
    如果（dptr == NULL）
        转到出去；
    if (!dptr->data) {
        dptr->data = kmalloc(qset * sizeof(char *), GFP_KERNEL);
        if (!dptr->数据)
            转到出去；
        memset(dptr->data, 0, qset * sizeof(char *));
    }
    if (!dptr->data[s_pos]) {
        dptr->data[s_pos] = kmalloc(量子, GFP_KERNEL);
        if (!dptr->data[s_pos])
            转到出去；
    }
    /* 只写到这个量程的末尾 */
    if (计数 > 量子 - q_pos)
        计数=量子-q_pos；

    if (copy_from_user(dptr->data[s_pos]+q_pos, buf, count)) {
        retval = -EFAULT；
        转到出去；
    }
    *f_pos += 计数；
    retval = 计数；

        /* 更新大小 */
    if (dev->size < *f_pos)
        dev->size = *f_pos;

  出去：
    向上（&dev->sem）；
    返回retval；






}

ssize_t scull_write(struct file *filp, const char _ _user *buf, size_t count,
                loff_t *f_pos)
{
    struct scull_dev *dev = filp->private_data;
    struct scull_qset *dptr;
    int quantum = dev->quantum, qset = dev->qset;
    int itemsize = quantum * qset;
    int item, s_pos, q_pos, rest;
    ssize_t retval = -ENOMEM; /* value used in "goto out" statements */

    if (down_interruptible(&dev->sem))
        return -ERESTARTSYS;

    /* find listitem, qset index and offset in the quantum */
    item = (long)*f_pos / itemsize;
    rest = (long)*f_pos % itemsize;
    s_pos = rest / quantum; q_pos = rest % quantum;

    /* follow the list up to the right position */
    dptr = scull_follow(dev, item);
    if (dptr =  = NULL)
        goto out;
    if (!dptr->data) {
        dptr->data = kmalloc(qset * sizeof(char *), GFP_KERNEL);
        if (!dptr->data)
            goto out;
        memset(dptr->data, 0, qset * sizeof(char *));
    }
    if (!dptr->data[s_pos]) {
        dptr->data[s_pos] = kmalloc(quantum, GFP_KERNEL);
        if (!dptr->data[s_pos])
            goto out;
    }
    /* write only up to the end of this quantum */
    if (count > quantum - q_pos)
        count = quantum - q_pos;

    if (copy_from_user(dptr->data[s_pos]+q_pos, buf, count)) {
        retval = -EFAULT;
        goto out;
    }
    *f_pos += count;
    retval = count;

        /* update the size */
    if (dev->size < *f_pos)
        dev->size = *f_pos;

  out:
    up(&dev->sem);
    return retval;






}

ssize_t (*readv) (struct file *filp, const struct iovec *iov,
                  无符号长计数，loff_t *ppos)；
ssize_t (*writev) (struct file *filp, const struct iovec *iov,
                  无符号长计数，loff_t *ppos)；

ssize_t (*readv) (struct file *filp, const struct iovec *iov, 
                  unsigned long count, loff_t *ppos);
ssize_t (*writev) (struct file *filp, const struct iovec *iov, 
                  unsigned long count, loff_t *ppos);

结构iovec
{
    void _ _user *iov_base;
    __kernel_size_t iov_len；
};

struct iovec
{
    void _  _user *iov_base;
    _ _kernel_size_t iov_len;
};

一旦你装备了四件 通过以上方法，即可编译并测试驱动程序；它会保留您写入的任何数据，直到您用新数据覆盖它为止。该设备就像一个数据缓冲区，其长度仅受可用实际 RAM 数量的限制。您可以尝试使用cp、 dd和输入/输出重定向来测试驱动程序。

Once you are equipped with the four methods just described, the driver can be compiled and tested; it retains any data you write to it until you overwrite it with new data. The device acts like a data buffer whose length is limited only by the amount of real RAM available. You can try using cp, dd, and input/output redirection to test out the driver.

这 free命令可用于查看空闲内存量如何根据写入scull的数据量而收缩和扩展。

The free command can be used to see how the amount of free memory shrinks and expands according to how much data is written into scull.

为了更有信心一次读取和写入一个量子，您可以 在驱动程序中的适当位置添加printk ，并观察应用程序读取或写入大量数据时会发生什么。或者，使用 strace实用程序监视程序发出的系统调用及其返回值。跟踪cp或ls -l > /dev/scull0显示量化的读取和写入。第 4 章详细介绍了监控（和调试）技术

To get more confident with reading and writing one quantum at a time, you can add a printk at an appropriate point in the driver and watch what happens while an application reads or writes large chunks of data. Alternatively, use the strace utility to monitor the system calls issued by a program, together with their return values. Tracing a cp or an ls -l > /dev/scull0 shows quantized reads and writes. Monitoring (and debugging) techniques are presented in detail in Chapter 4

本章介绍了以下符号和头文件。struct file_operations和中的字段列表struct file这里不再重复。

This chapter introduced the following symbols and header files. The list of the fields in struct file_operations and struct file is not repeated here.

在第 2 章中，我们建议 你建造并安装您自己的内核，而不是运行您的发行版附带的库存内核。运行自己的内核的最重要原因之一是内核开发人员已在内核本身中内置了多个调试功能。这些功能会产生额外的输出并降低性能，因此它们往往不会在发行商的生产内核中启用。然而，作为内核开发人员，您有不同的优先级，并且会很乐意接受额外内核调试支持的（最小）开销。

In Chapter 2, we recommended that you build and install your own kernel, rather than running the stock kernel that comes with your distribution. One of the strongest reasons for running your own kernel is that the kernel developers have built several debugging features into the kernel itself. These features can create extra output and slow performance, so they tend not to be enabled in production kernels from distributors. As a kernel developer, however, you have different priorities and will gladly accept the (minimal) overhead of the extra kernel debugging support.

在这里，我们列出了配置选项 应该为用于开发的内核启用。除非另有说明，所有这些选项都可以在您喜欢的任何内核配置工具的“内核黑客”菜单下找到。请注意，并非所有体系结构都支持其中一些选项。

Here, we list the configuration options that should be enabled for kernels used for development. Except where specified otherwise, all of these options are found under the "kernel hacking" menu in whatever kernel configuration tool you prefer. Note that some of these options are not supported by all architectures.

我们将重新审视 一些 当我们研究追踪内核问题的各种方法时，我们会考虑上述选项。但首先，我们将了解经典的调试技术：打印语句。

We will revisit some of the above options as we look at various ways of tracking down kernel problems. But first, we will look at the classic debugging technique: print statements.

最常见的调试 技术就是监控，在应用程序编程中，监控是通过 在适当的位置调用printf来完成的 点。当您调试内核代码时，您可以使用 printk实现相同的目标。

The most common debugging technique is monitoring, which in applications programming is done by calling printf at suitable points. When you are debugging kernel code, you can accomplish the same goal with printk.

printk(KERN_DEBUG "我在这里：%s:%i\n", _ _FILE_ _, _ _LINE_ _);
printk(KERN_CRIT "我被毁了；放弃%p\n", ptr);

printk(KERN_DEBUG "Here I am: %s:%i\n", _ _FILE_ _, _ _LINE_ _);
printk(KERN_CRIT "I'm trashed; giving up on %p\n", ptr);

#echo 8 > /proc/sys/kernel/printk

 # echo 8 > /proc/sys/kernel/printk